Possibility to use a window-based approach

[rszabo]

Hello

Candy is awesome, but lacks a multi-window view which probably is expected these days. Is there an interest from this community to improve the GUI of Candy?

I.e., only one chat can be visible at all times. The code, at least version 1.0.9, has internal events that determines the active chat based on the current tab selection.

The above picture shows the Candy implementation in Specimen (https://specimen.me) but I had to tear a part larger parts of Candy 1.0.9 in order to:

• Separate windows from tabs; one designated tab location, one parent to hold the created windows and their chats
• Handle events at a higher level such as active chat ...leaving the current GUI-code unusable as patch.

However, the hacks are crude yet simple:

• Introduce a Window Manager of sorts (I used jquery.WM.js with a custom wrapper)
• Replace or extend existing methods in Candy such as tabClick, tabShow, init etc to draw contents onto the Window Manager

Maybe someone else has already begun working on this?

[mweibel]

I don't think we'll incorporate a Window Manager or something like that. However what I think is that there should be a way to make changes like this more easy by abstracting the view updates more.

I also thought about using React for creating the view in the future but this would be a major change..

I'll think about this, but maybe someone else has an opinion on that already? @benlangfeld / @melissanoelle?

[malakada]

I would love to see the views abstracted more. Right now, a lot of candy relies very heavily on absolute positioning (unless overriden in a plugin) and the class names are expected to be in certain positions within certain elements and named certain things... which is not always clear. It would be kind of cool if Candy was ignorant of the DOM and just told where to put things/display things.... but I'm not very sure (or even just regular sure) that that would be a) feasible, or b) easy to use.

I'm not sure how I feel about using React. I would need to think on it more over the weekend. I keep hearing about it, but haven't put any time into learning about it yet--just not enough time to pass around in the world, y'know? :)

However, It IS possible to override Candy's interface into something radically different than it is by default... though it's not very easy/intuitive and if there was a clear way to make this easier/better I would be all over it.

[rszabo]

Well, yes, I did it but only because I didn't think I would upgrade Candy (silly, silly). I think we'd be able to solve this easily together.

1. Introduce new primary objects of Candy

• One for roster, one for current private chats and one for mucs (or object with keys for the two latter)
• In the initialization-phase of Candy, define selectors where item should appear:
  • { tabs: elTabs, windows: elWindows, debug: [], ... }

2. Keep chat items more structured; I had problems determining which chat item I was manipulating (muc/private).

3. Keep current states more obvious, i.e. getActiveWindow() could return the object of whatever is currently active, i.e. a MUC-object.

Most of these things could be done as plugins, making it easier to implement new functionality without disturbing the core. Candy is already a very good UI representation of Strophe, and could be even better. I noticed tons of stuff in the code that I'd rather move to plugins, i.e. everything related to sound and toolbars.

I looked through React and had serious problems with their semantics. Mustache that you're currently using is sufficient, isn't it? I'm going to mention AngularJS, but it would probably only bloat Candy in the end.

[mweibel]

Your proposal sounds like a good way forward.

React is actually the easiest framework for stuff like this, straightforward and doesn't get in your way. AngularJS is IMO not a good fit for this type of project: too bloated and their documentation seriously lacking (still). I'm using AngularJS at work and I don't like it at all, even though there it's the perfect fit.

With Mustache, and the general way how we do DOM updates is the problem that we have to assume a lot about the structure.

[rszabo]

Yes, I certainly agree that the DOM must be taken out of all calculations. I suggest that besides planning, the first thing to do is to upgrade the core of Candy to properly delegate our objects, and remove all static names from the code.

@mweibel Mhm, figured I'd mention it anyway .) Indeed, at work we got some minor issues as well.

Regarding React my problem is only its semantics. Very weird. On the other hand, I don't have to work on those parts so it's fine by me. :)

[mweibel]

What exactly do you mean with Semantics? It's certainly a new way how to do it. I use it in a personal project and it needs little time to get used to it, but it's actually worth it.

If it applies to Candy well I don't know yet, I'm currently thinking about how to do it properly. My thoughts was that when we use React, everything is a component and if you'd need to change the behaviour of it, you could just overwrite the component. But this is just an initial thought, will have to think about it how to do it properly.

[rszabo]

I won't argue with you as I haven't used React nor been accustomed to it. Things like 'return ()' is awkward and left a sour taste.

Of course, it's up to you. Either way, I need to upgrade to the latest version and start analyzing all the new goodies.