On 22/05/07, David Baelde <[EMAIL PROTECTED]> wrote:
Hi Peter, Nice to see you stuff arriving on the SVN. I just moved rocket in a directory next to liquidsoap's: I believe that the new generation GUI should be a rather large project which will get its own releases, branches, etc. I'm also glad to see that you're happy to stick to pygtk. Finally, rocket is a nice name, but it's not very soapy and not very distinctive either ;)
That's fine, rocket is just a name for now but I don't get why it's ls anyway ;) I think pygtk is where our biggest power can be, an excellent all in one pygtk installer exists for windows, as discussed with toots I can put liquidsoap into eventually an installer which can check if the user has pygtk installed and if not install it.
Another major aspect about the GUI is that in my current design I've moved > away from the detaching window form of the previous GUI, I need suggestions > on ways to handle this. Since some users might want to have multiple aspects > of the GUI visible at once and I don't want it to become an unorganized > chaos every time the program is opened. I don't know how much you tried the current liGuidsoap. Although each widget can be ran independently in its own window, the main program liguidsoap starts widgets in notebook tabs, much like your current mockup. I'm not a big fan of the separated windows, however I feel that only one notebook is too limited. It could be nice to have an interface allowing arbitrary horizontal and vertical splits (much like vim/emacs) to give the user the ability to choose the layout of its controls. Same as your colors, it would be neat to reming the layout from one session to another.
I will design the widgets within the single notebook for now and then move beyond a single to some user accessible layout manager setup contained within a single frame, I think we need to completly break away from having moveable mini windows. It's messy and will just annoy people. I'm also not sure to understand the intended design of your tool. In
the old design, one controller (one tab) controlled exactly one node in a liquidsoap script, not doing anything more. This is probably not the best way. For example, I like the first tab in your demo, where one can see the status of all the output nodes. However, one advantage of this simple architecture is that it fits any liquidsoap instance, whatever nodes are there. Will it still be possible with rocket or are you targetting specific instances of liquidsoap?
The ideal situation would be complete monitoring of every node in the network, each running seprately but can be accessed and can communicate together. This is a very very very very long term goal and can certainly sink to the bottom of the TODO, but it also comes in with what communications protocol we choose. It's more so to tell the DJ what is happening with the stream, another ideal feature would be able to pipe out the output stream to the DJ's desk, so they know whats going out. However my current rough sketch of the status page I pretty much hate right now, it's ugly and needs a clean gui. I'm thinking of using more button orientated approaches to display key data and have certain ones toggleable. Firstly with the interacting process design that this centers on, we don't want our day in/day out dj's any control of the streams, hence we need to have them read only and just give the gui details about whats happening, my intentions already are shown by a stream having a red background. If it's red they can't touch it, a bette rsolution for this that I will implement is probably a button with a padlock, or just a box. Another core button is the status of the stream, ie 'is it active?' and a colour scheme like traffic lights. Green - Active, Amber - Available but Blank Red - UnAvailable The other main part of the status is 'What's next?', this can then let users see/select what audio input to use. However this needs great consideration on usability fronts, since a DJ will need quick access to changing anything on this stream. However I do think the status screen will be mostly read only, if anyone has any ideas for how we can enhance usability then please let them be known. About the jingle board: it looks like a convenient widget. But how is
it supposed to be setup? From earlier discussions, I guess it controls a request.queue() or request.equeue(), but how does the GUI know the list of jingles? Again, a nice thing would be to save this information from one time to another: the admin configures the GUI and the DJ just uses a predefined layout.
Ah ha! Implementation, It's nothing that I've spent a great deal of time on since I'm more concerned at the moment of getting some good gui components together. Saving of Jingle boards is an absolute must and a heavy section on User Control is going to have to be exercised in this area. Such that Studio management can setup the main jingle board, it has all the station's branding and this is done within their account. Then all the dj's have access to it but cannot modify it. User issues are something I need to read about, since it's quite tricky to get right. However I still want to give DJ's the ability to create their own Jingle boards and then save them, oh and I want to increase the tab size of the gtk notebook, just gotta find how to.
One main aspect of the GUI I will be heavily developing is User Control, > since it is assumed that the GUI will be in use in studio environments with > multiple users. Therefore we don't want users messing around with key studio > jingle boards and being able to touch the streams directly, some of these > requirements will come under user control within the main daemon and there's > plenty of time to discuss what strategy the team can take. > - From what myself and David B were talking about on irc today, there's the > choice of telnet, telnet + ssl, CORBA or even Operating system specific > sockets for communication (any more please add). Each of them come with > their own distinct advantages and it'll be good to have a full discussion of > which would be the best suited. At some point, the protocol for interacting with liquidsoap will probably have to evolve to something more structured. However, we can already do a lot with the current protocol, and have a lot more on the TODO list.. But your question is not about the protocol, it's about the medium. Or rather, I think you're mixing both questions. Telnet used to mean "remote shell"; as such it is very outdated by much more secure ssh. I use the word "telnet" because it still refers to a convenient tool for interacting with a server (liquidsoap) using a human-readable plain-text protocol like ours. What you see in the telnet command is exactly what is carried through sockets -- and by the way, we do use the socket API directly. Using the word "telnet" may be a bad choice because it has lead several persons to believe that this was necessarily a cheap hack. In my sense, HTTP, POP and IMAP are also telnet-compliant protocols, and the development of our protocol won't be stuck because we use this so-called "telnet" interface. There is only one protocol for interacting with liquidsoap, but there are already two available mediums: tcp sockets and unix sockets. The first ones are weak, because the is no password, so (at least) any user of the host machine can control liquidsoap. SSL could indeed be a simple solution to that problem. Unix sockets offer more fine-grained permissions, actually the same as for files under unix. I don't know what CORBA can bring us. Discussion about the protocol could be useful, although I don't feel an urgent need for it right now. Discussion about the media are open, but in that domain coders are most welcome: it doesn't hurt to add new mediums, as it wouldn't invalidate the two existing ones.
CORBA is to do with distributed objects and it exists in many languages, including caml and python. The effects of it is that you can use Remote Method Invocation on Modules and also have the features of call back, it abstracts a lot from the socket layer and can make communicating processes quite powerful and simple to program. Cheers.
-- David ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Savonet-devl mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-devl
