From: Boris B. <bo...@ic...> - 2002-03-27 19:06:59
|
On 26.03.2002, Christian Kreibich created this extraordinary piece of literature, which I will thankfully quote in the following: > > > > Hi Boris, > > > > > > Boris Buegling wrote: > > > > > > Hi fellas. > > > > > > I've completed a proof-of-concept implementation of the widget server. It only > > > supports a simple ok-cancel dialog atm. You can get the source here: > > > > > > http://icculus.org/~boris/ewidgetd.tar.bz2 > > > > > > It has a gtk-1.2, ewl-cvs and qt-3.0 backend, as well as a little separate ipc > > > library. Would be good if you try it out and gimme feedback about it. > > > > I just had a look at it and here's what I'm thinking. First of all > > thanks for investing the time and coming up with this. I'll start with a > > summary of how I think the thing works, just to make sure I understood > > it correctly. The modules involved are: > > > > libewidget > > ========== > > Client library of the widget server. You can pass the library a file > > name which contains the parameters for a pre-defined dialog in xml. The > > file contents get sent to the server using libeipc. > > > > > > libeipc > > ======= > > Simple wrappers around reading from/writing to a unix domain socket. A > > single callback function can be defined which gets called after > > accept(). The handler itself has to read the data from the socket via > > the library's read wrapper. > > > > > > libexml > > ======= > > uses libxml to parse xml data contained in a filename, and provides a > > mechanism to call a given callback function. XML elements with special > > names are interpreted as a dialog type identifier and parameters for > > these dialog types. > > > > > > server > > ====== > > The server reads data from the client using libeipc's mechanisms and > > switch-cases through the recognized dialog tpye identifiers. When a > > dialog type is recognized, a process is forked which calls the dialog > > creator with the given parameters. When a dialog is closed, a callback > > in the server is called, which puts together xml data containing the > > result parameters of the dialog. > > > > > > libwtk > > ====== > > manages the actual dialogs. when a dialog is created, the event loop is > > started, when the dialog is closed, a handler function is called, then > > the event loop is terminated. The handler has a special name and must > > exist in the code the library is linked to. Here, this is the server > > code. > > That's how it works. > > > > Okay. I'm aware that this is just proof-of-concept, so some of the > > things are temporary of course. I'll comment on everything that I found > > worth commenting regardless. > > > > * The current libeipc is a good start, but it I think it's too dumb. The > > callback function must call eipc_read itself to get the string that was > > received, that's not good. I'd simply offer functions to send/receive > > strings, ints and floats in libeipc, that's it. The current callback > > function can be replaced by normal handlers called from a select() loop > > when something arrives on a libeipc fd. That does anything we need at > > the moment, and if someone really really feels the need to send xml data > > across, he can still use eipc_send_string(). I wanted to keep libeipc a bit more generic, but if we don't want this, this approach is certainly better. > > > > On top of libeipc, you're encoding data in xml before it gets sent > > across the wire. I don't think I see the benefit of using xml here, for > > the following reasons: > > > > - Putting xml data together manually is horrible: > > > > void backend_notify (char *signal) > > { > > int fd; > > > > fd = eipc_connect (CLISOCKET); > > eipc_write (fd, "<?xml version=\"1.0\"?>\n\n<ecallback>\n<type>"); > > eipc_write (fd, signal); > > eipc_write (fd, "</type>\n"); > > eipc_write (fd, "</ecallback>\n"); > > close (fd); > > } > > > > There either needs to be a decent library to create xml elements and > > serialize them automatically, or we shouldn't do it at all. Right now > > you're using (temp) files as containers for the xml data, in this > > particular case you need to call eipc_write() four times just to get the > > xml tags right. Also, everything is passed as a string. > > Basically, I like xml. It's easier to use than plain stuff imho, so I chose it. You can prove me wrong. > > - The current xml parsing mechanism needs to receive the full xml > > document before the data is passed on. Using a sax parser would be much > > better, because when you've seen a type tag that contains > > "ok_cancel_dialog" you could correctly parse the remaining parameters > > etc. > > Wanted to do this a bit later. > > But I think we can keep things a lot simpler for our purposes. If we > > have an api for libeipc as I described above, people can still send xml > > across when they really want to, here I don't see the benefit. > > > > * The backend implementations in multiple toolkits are nice, but don't > > really make sense, because every dialog will need to be implemented > > multiple times to benefit. Either we need a a metatoolkit, or we should > > stick to a single toolkit. We have decided to use gtk, and I think that > > is good. It'll really really help when we need to create dialogs for > > epplets, because epplets can basically be simple gtk apps, except that > > their main window is rendered in a different process on an evas. > > Metatoolkit would be a lot of work, I thought it would be better to first implement some dialogs, which we need and replace the backend later. > > I do not intend to keep all options open and implement a sketchy design > > just because there is a slight chance that some parts of the gui code > > (the larger tools will remain gtk for the predictable future anyway) > > *may* eventually be using a different toolkit. I'm very gtk-biased at > > the moment, because I'm really tired of the toolkit issue. I'm tired of > > trying to stay independent mainly because it complicates things a lot. > > Others may disagree. > > I don't think that it makes a big difference for the programmers. I hate it when an app just works on one toolkit, so it would be cool to support the three. Apart from that, it is quite bad to not use ewl, our native toolkit. At least this should be in the server. > > * fork() and event loop handling. You're using a fork() and event loop > > per dialog. I think you've tried to separate the server core from the > > gui implementation as much as possible, which is cool. My opinion > > however is that we should marry ourselves to gtk more than that and make > > the server a gtk app that receives commands from libeipc within gtk's > > event loop and then simply hide/show the dialogs in the ipc handlers. > > That's a lot less overhead, cleaner and easier to code. > > Even if we stick to gtk, we should keep gui and server separate, because we might want to use Ewl later. I think it's worth the overhead. > > The point of the server was to separate the wm/fm event loop from the > > dialog gui event loop, not to provide multiple toolkit dialog > > implementations. > > Then I misunderstood something. But we can do both at the same time. I don't really understand it now (all night in the matrix [disco in berlin]), could you explain it a bit ? > > * You're declaring functions in the library headers and define them in > > the code that the libraries are linked to. That's not scalable and > > should be replaced by function pointer structs or similars. > > Later :) > > * Solid select() event loops are still missing, so the basic code layout > > isn't there yet, but that's no problem really. > > Hmmm, can you explain a bit ? > > These are my initial impressions. I think you're providing a good basis, > > thank you for your efforts. I'd just keep things a good deal simpler. In > > particular I'd nuke libexml and libwtk. Comments by others? > > Maybe we don't need xml, but i think we should keep wtk. > > Cheers, > > Christian. > > -- > > ________________________________________________________________________ > > http://www.whoop.org > > > > _______________________________________________ > > enlightenment-devel mailing list > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Boris Buegling <bo...@ic...> "Sleep less - live longer." - "Ok good, 1 down... Now all I need is beer, video games and hacking to be linked to living longer and I'm set." |
From: root <bo...@ic...> - 2002-04-15 15:56:08
|
Hi all. On 15.04.2002, Christian Kreibich created this extraordinary piece of literature, which I will thankfully quote in the following: > > Hi. > > > Here's a list of issues I see in the current ewidgetd code. I would > normally never go through someone else's code and point out all these > things in so much detail, you'll see why I did so in this particular > case below. > > [ Comments to the code remove ] > Thank you for giving up so much time to go through the code. I really appreciate this. > Boris Buegling wrote: > > > > Hi. > > > > Hmm, on second thoughts, a mail about ewidgetd would have been more efficient. > > I don't know if you have ever heard of social skills or the like, but > this was not a matter of efficiency, it was one of politeness. > I see one basic communication problem here: You think that everything I say is literally meant as such and I do not *always* mean it like that. You didn't understood this right, it was my way of saying: "Sorry, I was wrong on this.". > > * Usage of C++ > > > > I don't like c++ myself, > > Well then don't use it when you don't have to. > Yeah, but I thought I had too. On second thoughts and after reading your comment, it is not necessary to use it in this case. > > but I have done the wtk in c and I know that it would > > be very ugly with all those ifdefs over the place > > This statement is pretty much as unqualified as it gets, and shows that > your experience in both C and C++ must be rather thin. Proper use of > #ifdefs requires basically identical amounts in both C++ and C. > After reading your comment to wtk above, you are right. I just did not see this approach. maybe because of a lack of skill. > > and it wouldn't be as > > extensible as the c++ version. > > Your usage of C++ doesn't increase extensibility in any way. > Compared to my first implementation it does. Compared to the one you pointed out, certainly not. > > Apart from this, all code that uses WTK must be > > compiled with g++ anyway, because it links to Qt, which is written in c++. > > No. As I pointed out above, if you would encapsulate each toolkit > implementation in a separate lib, you could hide the implementation > language of the toolkit completely behind an exported C interface. > Badly formulated by me. What I meant is that the code that uses Qt must be compiled with g++. Or is it possible without it ? > > A > > wtk without support of Qt would be quite useless, so any wtk-project has to > > use g++, whether or not I'm using C or C++. > > No, see above. And like I told you before, it is not acceptable in this > project to have libraries with a C++ interface when there is even a > remote chance that other parts of the project might need these > libraries. Plus there is no need for a C++ interface here. > Right, after seeing your plugin suggestion. > > So it would be good if I get some feedback about: > > > > * what do you think is missing what you certainly expected > > Well, a reasonable design and thorough experience with C. Sorry for > being this blunt. > Yes, both are missing in this thing. The main reason is, that is is basically my first proof-of-concept implementation from about 3 weeks ago. I did it mainly to get some feedback about it. I got several stuff to LibEipc, which really showed me that it is not good like it was done. I used Raster's and your suggestions to do a better version. Then there was the reimplementation of WTK in C++. That's basically everything I've done. I didn't expect it to be added to CVS this soon, because the design was not ready and the code was a first try. It seems to me that both you (all devels) and me got much stuff wrong. What is currently in CVS (or not anymore), is the proof-of-concept code. I wanted to know what you basically expected from a widget server, not really in terms of design and implementation, but in terms of the general interface and how it should later interact with the rest of E. For example, I did not know that we want a event loop for the widget server, but I thought that we want it to show a configuration dialog, which say OK or CANCEL somewhere and to send all the configuration options back (like the user wants no sound and 4 virtual desktops or whatever). It seems that you expected something very different and so it is certainly not what you want. The current widget server is about 3-5 hours of work including the learning of autofoo, which I did not know before. It was certainly not ready for CVS. > > I chose to use C++ for WTK mainly because Till and Smugg told me, that it would > > be better. If you remember a post here from me some time ago, I have done the > > stuff that is in WTK now in C, but it sucked. > > It is not better. See above, and see Chris' reply. > Right, it was also not correct that Till and Smugg told me that. I misunderstood Till and mixed up Smugg with somebody else. > > I have even written autofoo support for ewidgetd, instead of using my own > > Makefiles, although I hate it. > > Well that's what we're using, so you'll have to deal with it. > Sure, just wanted to show that I sometimes do things others expect me :) > The reason why I mentioned all the coding flaws above is to point out > the following: the way things are shaping up, we don't think you have > the necessary skills for this project and it seems like we'll be mostly > walking you through the implementation of this widget server. This will > be unneccesarily painful and time-consuming for both you and us. It was > a mistake, mostly on my part, to agree on handing out CVS access to you > this quickly. My apologies to the other developers for the resulting > mess. > I was also quite surprised to get the CVS access. I thought it would be better to have it seperated until it is good enough to be used in some way. There are many issues in my implementation and I didn't expected it to be added to CVS this soon, so I'm not really surprised that it is removed again. > To stop this from becoming even more unpleasant than it already is, > we'll revoke your CVS rights for now because the quality of your code > and your attitude really don't suffice. You're welcome to still send > patches, if they're good we'll gladly use them. > OK, so you don't want me to redo the thing now after I really understood what its purpose is. I now have some more time for coding, so I could do some re- design and re-implementation, but I don't know if you want me to do it (of course not in the CVS tree, but sending some URL when I have a reasonable thing ready). > > "Real programmers don't comment their code." > > ;-) (This sign means that the statement above is meant humorous, please don't > > comment it) > > This is one more example that illustrates how you have managed with just > a few emails to make pretty much all of us think of you as an impolite, > ignorant and arrogant individual with rather questionable opinions about > things and a serious lack of communication skills. > Great that i succeeded ;-) Maybe it was wrong to use my rather strange kind of humor in my mails. I am really a fan of good commented code and this is a common joke between me and some friend of mine. Sorry if you were offended. > Christian. > -- > ________________________________________________________________________ > http://www.whoop.org > > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Regards, -- Boris Buegling <bo...@ic...> "Links zu sein, heisst eben nicht, sich den Verhältnissen zu ergeben und die Misere mitzuverwalten, das ist lediglich konservativ." |
From: Christian K. <kre...@in...> - 2002-04-15 17:08:00
|
root wrote: > > OK, so you don't want me to redo the thing now after I really understood what > its purpose is. I now have some more time for coding, so I could do some re- > design and re-implementation, but I don't know if you want me to do it (of > course not in the CVS tree, but sending some URL when I have a reasonable > thing ready). You're always welcome to send patches or upload a tarball somewhere where we can look at it. Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Christian K. <kre...@in...> - 2002-03-27 20:01:52
|
Boris Buegling wrote: > > > > The point of the server was to separate the wm/fm event loop from the > > > dialog gui event loop, not to provide multiple toolkit dialog > > > implementations. > > > > Then I misunderstood something. But we can do both at the same time. I don't > really understand it now (all night in the matrix [disco in berlin]), could you > explain it a bit ? Well the basic problem with using anything other that ewl is that the other toolkits have their own event loops and expect everything else to be hooked into theirs. So we need a way to be running separate event loops for other widget sets. Hence the idea to move them to a separate process, the widget server. I don't think it makes a lot of sense to implement everything three times. And let me repeat: the config tools are using gtk. Even if the widget server supported multiple tookits, things would still be inconsistent. I really don't want to slow down your efforts for the widget server, I'm busy enough with essence and efsd. The xml use is really a red herring for me, so I'd appreciate other opinions. What definitely needs to go is the piping through the tempfiles, and if you want to keep using xml, you shouldn't be using it as directly as you are. Instead of void backend_notify (char *signal) { int fd; fd = eipc_connect (CLISOCKET); eipc_write (fd, "<?xml version=\"1.0\"?>\n\n<ecallback>\n<type>"); eipc_write (fd, signal); eipc_write (fd, "</type>\n"); eipc_write (fd, "</ecallback>\n"); close (fd); } it would be nicer to do XMLFile *xml_file = xml_file_new(); XMLNode *root = xml_create_element("ecallback"); XMLNode *ecallback = xml_create_element("type"); xml_node_add_child(root, ecallback); and then eipc_write(fd, xml_serialize_document(xml_file)); etc. The api is ficticious, just to explain my point. I do agree that it's a good idea to keep the toolkit replaceable, I just don't want to implement every dialog three times at the moment. Therefore I'd stick with gtk right now. Gtk's event loop is designed to make it easy to hook stuff into it, so it's easy. > > > * Solid select() event loops are still missing, so the basic code layout > > > isn't there yet, but that's no problem really. > > > > Hmmm, can you explain a bit ? You're currently forking a process per dialog and wait() for that process. What's missing is the event loop that blocks while no messages are arriving, and for that you should use a select() loop. What I meant is that in real use, libeipc will be used within select() event loops in both the client and the server. In the fm/wm this would be the ecore event loop, and in the server this should either be its own event loop (blocking when select() is called, waking up when messages arrive), or, supposing we use gtk only, hooked into gtk's event loop. The good thing about the widget server is that it neither needs to handle high volumes of traffic, nor multiple clients (at least right now), so it's very likely that we won't see buffer overruns. That makes things a whole lot easier. Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |