UI framework

[jbaron]

Invest in reusing existing UI framework or improve own code base. Things to look for:

1) Abstract HTML& CSS so almost everything can be done in TS. 2) Integrate well with TS (so typed declaration files should be possible) 3) RIA support 4) Fast, lean and not much overhead (doesn't have to support old browsers etc). 5)) Has widgets like:

• Tabs
• Flexible layout engine
• Tree
• Grid
• Menu

[cocodrino]

Hi jbaron..I saw your project in the google group but I didn't how advanced you're developing this..this look great although I can't try it jet...I was thinking do something similar to this but for f#...f# has intellisense in emacs :D ..

now maybe use angularjs could help you...angularjs is a javascript framework than help to create complex web apps in a simple, ordened, clear and testeable way without many lines of code (it's amazing how expressive is)...I think than angularjs with node-webkit could be the best combination..

the guys from angularjs (google) created a text editor, this is open-source and has nice features, maybe you could adapt to your editor https://www.youtube.com/watch?v=_O3-20FUJbg&feature=player_embedded , also this framework let you create reusable code, there are some interesting stuff like http://angular-ui.github.com/bootstrap/ http://mgcrea.github.com/angular-strap/ http://angular-ui.github.com/ give a look and let me know if you choose angularjs..I was interested in use adobe brackets but the code is a mess.....

[jbaron]

Thanks for bringing this to my intention. Just finished watching the video and it sure looks promising. The editor they build is also using Ace for editing itself. So it should be possible to reuse also some of that.

I guess I'll have to play with it to see what what the pros and cons are and what the effort would be to use this framework.

I played with many frameworks in the last few months, but not easy to find one that meets my requirements. So hopefully this can finish my search.

// Peter

On 31 jan. 2013, at 07:07 PM, cocodrino notifications@github.com wrote:

Hi jbaron..I saw your project in the google group but I didn't how advanced you're developing this..this look great although I can't try it jet...I was thinking do something similar to this but for f#...f# has intellisense in emacs :D ..

now maybe use angularjs could help you...angularjs is a javascript framework than help to create complex web apps in a simple, ordened, clear and testeable way without many lines of code (it's amazing how expressive is)...I think than angularjs with node-webkit could be the best combination..

the guys from angularjs (google) created a text editor, this is open-source and has nice features, maybe you could adapt to your editor https://www.youtube.com/watch?v=_O3-20FUJbg&feature=player_embedded , also this framework let you create reusable code, there are some interesting stuff like http://angular-ui.github.com/bootstrap/ http://mgcrea.github.com/angular-strap/ http://angular-ui.github.com/ give a look and let me know if you choose angularjs..I was interested in use adobe brackets but the code is a mess.....

— Reply to this email directly or view it on GitHub.

[cocodrino]

I've tried a lot of frameworks too (emberjs,batman,angularjs) but I chose angularjs basically for 2 reasons...first the code is better organized and modular, it's not hard maintain long code, also this let reuse and share code... 2) Is the option where I need write less code :D ..this is really concise...

the cons is the learning curve, use directives is a bit tricky at first, but also is the most powerful part...is better option spend time learning than spend time refactoring later :D ...

[jeske]

Have you considered node-qt or node-gui (gtk)?

https://github.com/arturadib/node-qt https://github.com/zcbenz/node-gui

..or Alternatively, using IronJS to create a MonoDevelop extension for type-aware typescript editing..

https://github.com/fholm/IronJS https://github.com/mono/monodevelop/tree/master/extras/JavaBinding/Parser

I think expecting a robust editor out of current HTML-DOM technology is just asking too much. There isn't a single rich/DOM based editor anywhere on the web that I'd consider "super reliable". They all have their quirks, which I personally think come from limitations in the HTML-DOM text-range APIs during content changes. TextDrive/AngularJS doesn't even work without running bleeding edge chrome with bleeding edge features enabled, and it's the simplest-of-simple text editors. IMO, robust custom text-editors are still a bit out of reach for HTML DOM UI. Wheras text-editors have been quite reliably produced using 2d UI kits for decades.

[jbaron]

I agree that HTML based editors are stretching what HTML/Dom can do at this moment. So yes, they are possible not as reliable yet as some of the more proven solutions around.

That being said, there have been some good improvements lately in JS/HTML editors. It seems that the popular approach is not to use the content-editable feature anymore, but a "hidden input" instead. This hidden input has the focus and is used for capturing the key strokes and then kept in sync with the content. This seems to be more predictable than the content-editable approach.

So far I use CATS a lot and I don't encounter too many issues with its editor component (Ace). It even surprises me at times. For example it loads and renders a large TypeScript faster than Sublime editor (not sure this is representative). And with all the momentum behind JS/HTML, this should only get better over time.

Before I started the development of CATS I did look shortly at some alternatives. However many of them seemed to be at an early stage and their JS bindings rather course-grained. But perhaps I should take another look (especially if the Ace editor would become a reliability issue).

[jeske]

For me the cursor is nearly always in the wrong place when there is punctuation at the end of a line.. If I click to the right of any of the lines in the sample, the cursor shows "before" the semicolon, but if I hit delete, it deletes the semicolon. Do you see this problem? This is on MacOS X.

[jbaron]

I never had this issue, but so far most of my testing is on Linux.

This could be related to the end-of-line differences between the various platforms. On Linux it is one character, on OSX en Windows typically two characters. And both Ace and TS have their own way of tracking this.

I'll have a look at it.

On 18 feb. 2013, at 12:26 AM, jeske notifications@github.com wrote:

For me the cursor is nearly always in the wrong place when there is punctuation at the end of a line.. If I click to the right of any of the lines in the sample, the cursor shows "before" the semicolon, but if I hit delete, it deletes the semicolon. Do you see this problem? This is on MacOS X.

— Reply to this email directly or view it on GitHub.

[jbaron]

One of the things I just checked in is that the editor should always use the same "end-of-line" character, regardless of the platform. I didn't test yet if this would solve your issue, but it might help.

[jbaron]

Started to investigate Qooxdoo as one of the possible UI frameworks. First results look promising, a very powerful framework with many of the required widgets out of the box.

[cocodrino]

jbaron atom is migrating to facebook react, react is pretty simple and fast, maybe would give it a check...seems the best option so far...(I think than brackets new version will use react too, because the main head in the project is interested in react too)...give it a look, seems to be the best way

[ztkavc]

If you consider newest stuff then I suggest that you look at Google's Polymer (web components) and material GUI elements.

2014-07-06 3:04 GMT+02:00 cocodrino notifications@github.com:

jbaron atom is migrating to facebook react, react is pretty simple and fast, maybe would give it a check...seems the best option so far...(I think than brackets new version will use react too, because the main head in the project is interested in react too)...give it a look, seems to be the best way

— Reply to this email directly or view it on GitHub https://github.com/jbaron/cats/issues/24#issuecomment-48100294.

[jbaron]

I did check it in the past. I think looks promising, and would expect to be used by other frameworks as a backend (so render widgets in the shadow-dom etc). However right now not may good widgets available (like a good tree widget etc)

[jbaron]

I published my trial with Qooxdoo sofar: https://github.com/jbaron/qx-cats

It is like a mockup of CATS done with Qooxdoo. Still a lot of things to be validated before can make an informed decision.

[maryo]

I am also a fan of Facebook React. Check these if interested: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://facebook.github.io/react/docs/flux-overview.html (pete hunt's talk, but the first talk is also cool) https://www.youtube.com/watch?v=-DX3vJiqxm4

But the fact is that probably all of those components would have to be created from scratch. It would also have to be integrated with TS a little bit more - typings (.d.ts) does not exist, JSX support (if used). And the same for Polymer/Web Components, i miss those desktop friendly widgets there.

I've checked the Qooxdoo. Those widgets UX is quite good (Win8). But the generated DOM looks full of inline styles. I actually can't find any external css there, looks like everything is generated by JS (even those styles)? I don't like this approach too much but maybe i just missed something. It also recalculates absolute positions when browser can do it smoother in some places, but the jQuery UI plugin also does it and most of others (it's not so easy for more complex and easily configurable layouts but mostly it can be done). I understand it would simplify the project a lot since those widgets are there and work pretty well.

[jbaron]

Maryo, do agree with most of your impressions of Qooxdoo, After making a mockup (qx-cats project), so far my findings:

Positive: 1) A very nice set of widgets, that meet almost perfectly what CATS need (tabs, toolbar, virtual tree, layout). Would reduce the CATS effort a lot. 2) Nicely abstract away HTML, so can do most in the TS editor with type checking benefits 3) Very well designed OO structure that feels natural in TS 4) Possible to have a good declaration file (mostly generated)

However: 1) Look and feel is mostly done true JS, although powerful, more difficult for certain tasks than CSS. 2) Framework even controls scrolling behaviour, giving it a non-native feel. 3) Build tool seems difficult to avoid since some settings can only be changed at build time and not runtime. 4) Smaller community than some other frameworks (however very helpful people).

So if they would have the same widgets but use more native capabilities (even at the expense perhaps of slightly different behaviour per platform), this would be certainly my preferred solution. Right now however I'm still only considering it.

[Mparaiso]

I just tested your project and it's important you benchnmark these different frameworks before picking one.

Right now cats has OK performances(on a Macbook )which is good ,compared to others WebIDEs like Atom or Brackets. Brackets is starting to get slower and slower unfortunatly.

So keep the project focused and responsive.Dont try to make it do everything,because as the project will grow in popularity people will ask for features... just concentrate on the core product,a Typescript/JS/IDE.

I wouldnt choose angular.While I did some some apps with it (like this one https://mparaiso.github.io/playground/ ) , I dont think the perfomances are that good.

React could be a better alternative. But usually what an IDE needs is a few widgets , a true webframework might be overkill,IMHO.

[jbaron]

I do agree that it should stay lightweight. I think the basic architecture (doing all the heavy lifting in a web worker) helps a lot to make it feel snappy. However when introducing a new framework, it should not feel slower.

[maryo]

If it was up to me then i would try React including JSX. But the JSX thing would not be so easy to integrate into TypeScript and TS is not so expressive like CoffeeScript is. Probably even impossible without modifiing typescript or creating an insane build tool. Also it would be better to write classes using normal typescript's "extends" keyword instead of "React.createClass" etc.

Because of this i would use WebComponents since Chrome 36 have native support so it could not be a performance issue and Node-Webkit (based on Chrome) is currently the only supported browser (or Polymer could be used but the performance in other browsers would be much worse).

There are not so many complex widgets it needs. It could be created from scratch and served using custom elements (like for example <ui-treemenu></ui-treemenu>, var tree = new UiTreeMenuElement; tree.addEventListener('collapse')...), maybe i could try to code the layout and the widgets if interested (i enjoy HTML/CSS coding sometimes) but ofc thats not a one day work and you already started this way (except the Web Components) and want to change :).

[jbaron]

For those interested there is a Cats branch called qooxdoo where I refactored major parts of the code to use the Qooxdoo framework instead. Not feature complete, but getting there.

[jbaron]

After some testing and refactoring, I came to the conclusion that (at least for now) Qooxdoo seems to be a good fit be used for UI components. Main findings include:

Upside:

• Results in much cleaner code base, with of course less emphasis on UI related components. We can now focus on the core, making a smart TypeScript IDE and less worry about UI related stuff
• Can remove the JQuery dependencies.
• Proven and tested code base for the Qooxdoo UI components, also used by many others projects.
• Has good architecture to deal with larger sets of data
• Easier to start contributing by others now due to available documentation for the Qooxdoo components and the more simple/consistent structure to understand
• Almost everything can be done completely in pure TypeScript using code completions etc. So no HTML/CSS magic that the developer has to worry about. This make the development really feel like a typical desktop application.

Downside:

• Slightly more overhead due to generic nature of Qooxdoo, not specific targeting Chrome and not always using latests/greatest HTML/CSS features. For example some more nesting of divs etc.
• Loose some control, since a framework will always have some limitations. Most likely within the look&feel department.
• Even the theming is done thought an API and not using CSS directly. This means an additional learning curve (although we can perhaps create a custom theme that uses CSS)
• What if the development for Qooxdoo comes to a hold.

Since the GUI layer is now a well defined API, in the future it can could be replaced for another Widget framework. However it became clear to me that developing such a framework from scratch is a huge task that takes time away from developing nice features in CATS.

For now I'll keep the Qooxdoo code in a separate branch, but I expect to merge this with the main branch once all the basic functionality is back in there.

Inviate you all to check out the qooxdoo branch already an let me know what you think of it so far.

[maryo]

Great. Few very tiny gui issues after few minutes: Does also the left/right panel content moves by few pixels when you click it? When resizing the columns in search bar, the scrollbar sometimes appears like the table was bigger than it's container even the cells are empty.

http://manual.qooxdoo.org/current/pages/desktop/ui_custom_themes.html This is the manual for theming? Would be great if Window > Theme applied the qooxdoo theme. I would try then to create a theme simmilar to the one i styled in master branch. The ACE themes could be applied separately.

But i see theming is not the top priority. Nice to see you are still working on it :)

[jbaron]

The link you send is indeed an intro about theming. To be honest, changing colours is a piece of cake (look at the Color.ts file in the src/cats/theme directory where I override one colour of the Simple theme), however changing some other aspects of the look&feel is more tricky. It is more powerful than CSS, but also more diffult.

Right now I basicly used the Simple theme and changed the background colour. Also in the code I changed some padding settings and disabled some decorators, however that is bad practice since it makes some other themes look worse. So I should change those settings also in the theme (like Appearance.ts).

On 02 Aug 2014, at 11:49, Marek Štípek notifications@github.com wrote:

Great. Few tiny gui issues after few minutes: Does also the left/right panel content moves by few pixels when you click it? When resizing the columns in search bar, the scrollbar sometimes appears like the table was bigger than it's container even the cells are empty.

http://manual.qooxdoo.org/current/pages/desktop/ui_custom_themes.html This is the manual for theming? Would be great if Window > Theme applied the qooxdoo theme. I would try then to create a theme simmilar to the one i styled in master branch. The ACE themes could be applied separately.

But i see theming is not the top priority. Keep the good work

— Reply to this email directly or view it on GitHub.