From: <ceh...@ma...> - 2003-05-12 21:23:32
|
On Monday, May 12, 2003, at 08:33 Pacific/Honolulu, Ernest Frigola wrote: > > (sorry for the formatting of my previous message) That's ok, it was freaking me out though! I took a minute before I realized it was actually an image, and not text! Haha > > Chad, > > On the first place thanks for your work. Your welcome! > > What i would like to see in GNUstep (or in one of this implementations) > is a cohesive and coherent User Enviroment like the one in NeXTStep 3.3 > described here: > > http://www.channelu.com/NeXT/NeXTStep/3.3/nd/UserInterface/ > 01_VisualGuide/VisualGuide.htmld/index.html > http://www.channelu.com/NeXT/NeXTStep/3.3/nd/UserInterface/02_Design/ > Design.htmld/index.html > http://www.channelu.com/NeXT/NeXTStep/3.3/nd/UserInterface/04_Window/ > Window.htmld/index.html > http://www.channelu.com/NeXT/NeXTStep/3.3/nd/ I would like the same! The only way GNUstep, as a desktop environment, will be better than KDE and GNOME is to ensure consistency in the UI. That is what users really want, whether they know it or not. If there is no consistency, than what you end up with is something nobody will use. It's the reality. Although WindowMaker is awesome, it really does not fit into this model of consistency. Anybody who has used WindowMaker with GNUstep realizes this. I'm not knocking WindowMaker, it is great code, just not quite what we need. I think that a combination of InterfaceWM and a separate Dock.app is ideal. I have to say that prefer the OS X style of Dock over the OpenStep one. For instance, I think that the user should be able to put documents in the dock. I also think that the openstep style of having two separate places for App icons is confusing to the typical user, they wonder why the can grab an App ion and put *it* into the dock, but cannot put a miniwindow icon there as well. Stuff like that. So, what this means is that if I do write a Dock.app (and it's looking like I will), it will be in the basic style os OS X. Now, the question remains, what to do with the miniwindows? Do we put those in the Dock as well (like OS X), or de we put them in the lower part of the screen? Having a dock to handle these types of things will make the creation of InterfaceWM much easier since it will be able to defer these window handling issues to a dock. There just needs to be a method of interaction between InterfaceWM and Dock.app, the natural choice would be via Distributed Objects, of course. > > IMHO the pieces are available but they need more integration: > > - Window manager: Interface window manager (http://interfacewm.sf.net) > & > Jewell Objective-C (http://mjr.towers.org.uk/xwinman.html) > > - Workspace manager: GWorkspace.app Both good, not familiar with jewell though, it's written in objc but does it uses GNUstep frameworks? > > - Dock: I think GWorkspace.app includes Backgrounder.app that can take > care of the root window and a Fiend where you cand attach applications > and switch workspaces. There's also a beta Panel for GNUstep > (screenshots here: http://wiki.gnustep.org/index.php/Panel) but IMHO a > gnome/kde-like panel is not a good idea for GNUstep. Fiend is ok, but is it not everything a real dock can be. I also think that these two things should be separate processes. I've heard of the Panel and seen the screenshots, but have never seen any code?!? I also don't think that a GNOME/windows/KDE style panel is good, that is garbage, "Start" menus are garbage. > > For me it's not clear the rule of these applications in the GNUstep > environment. Should the Workspace Manager (GWorkspace.app) take care of > the root window/desktop instead of the window manager? is this > documented somewhere? is somebody working in this? Hmmm, Who owns the root window? Good question! In the traditional OpenStep, the root window was blank, just a color or whatever. Os X allows the placement of icons and such on the desktop, which I find very, very, convenient and like. I think that if we allow files to be put on the desktop, then GWorkspace should own it. > > On the second place i suggest you as a project to port KHTML (or Apple > safari's webcore) to GNUstep: I would very much like to! no objc++ though. Webcore is completely objc++. A lot of it is code which acts as a bridge between QT and Cocoa. > > http://mail.gnu.org/archive/html/discuss-gnustep/2003-01/msg00157.html > http://developer.apple.com/darwin/projects/webcore/ > > Have you looked at it? Yup, i have also looked as the OMNI framework stuff and ported OMNIBase over to GNUstep. However, there is really no point in this because the OMNI license does not permit me to distribute the modified source. Strangely enough I can distribute the altered binaries. > > Thanks again and good luck! (i'm looking forward for the next release > of > prometeus) Awesome! chad > > -- Ernest > > -- On Sun, 11 May 2003 23:08:29 -1000 > ceh...@ma... wrote: > >> I'm planning on writing an application while I'm away for a month, I >> leave Monday night so if you would like make suggestions about what to >> >> write please reply quickly! >> >> My ideas are: >> >> A Dock.app >> a SlideShow.app (like powerpoint) >> Maybe even a *simple* web browser (in objc) >> >> what would you guys like to see made? Any suggestions? >> >> >> Chad >> >> Reply quickly, I leave tonight! >> > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise > solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |
From: Nicolas R. <ni...@ro...> - 2003-05-12 21:35:03
|
On 2003-05-12 20:56:18 +0000 ceh...@ma... wrote: Hello, > I think that a combination of InterfaceWM and a separate Dock.app is ideal. I have to say that prefer the OS X style of Dock over the OpenStep one. For instance, I think that the user should be able to put documents in the dock. I also think that the openstep style of having two separate places for App icons is confusing to the typical user, they wonder why the can grab an App ion and put *it* into the dock, but cannot put a miniwindow icon there as well. Stuff like that. > > So, what this means is that if I do write a Dock.app (and it's looking like I will), it will be in the basic style os OS X. Now, the question remains, what to do with the miniwindows? Do we put those in the Dock as well (like OS X), or de we put them in the lower part of the screen? Imho, the "Dock" should be some separate program, perhaps communicating with the window manager (IWM ?) to handle iconfied windows ... So that you could have a program with a NeXT-like dock, or an Aqua-dock, or even a panel or whatever. The "Dock" program (whatever its representation) only needs to receive startup notification of programs (already the case for gnustep apps), iconification and close notifications too. Perhaps others notifications are needed. > Having a dock to handle these types of things will make the creation of InterfaceWM much easier since it will be able to defer these window handling issues to a dock. There just needs to be a method of interaction between InterfaceWM and Dock.app, the natural choice would be via Distributed Objects, of course. Distributed Notifications would be fine. >> - Dock: I think GWorkspace.app includes Backgrounder.app that can take >> care of the root window and a Fiend where you cand attach applications >> and switch workspaces. There's also a beta Panel for GNUstep >> (screenshots here: http://wiki.gnustep.org/index.php/Panel) but IMHO a >> gnome/kde-like panel is not a good idea for GNUstep. > > Fiend is ok, but is it not everything a real dock can be. I also think that these two things should be separate processes. I've heard of the Panel and seen the screenshots, but have never seen any code?!? I also don't think that a GNOME/windows/KDE style panel is good, that is garbage, "Start" menus are garbage. Well the code was never officially released, because it lacks some features to be really user friendly ... Anyway the code is downloadable on http://www.roard.com/download/Panel.tgz (caution : crappy and unsupported code for the moment) > Hmmm, Who owns the root window? Good question! In the traditional OpenStep, the root window was blank, just a color or whatever. Os X allows the placement of icons and such on the desktop, which I find very, very, convenient and like. I think that if we allow files to be put on the desktop, then GWorkspace should own it. In my opinion, putting files on the desktop is *not good*. Well, at first it sounds like a good idea, but you'll end with your desktop filled with files quickly. And the reason why NeXT choose to not let people put their file on the desktop is quickly remained : because generally you have *something* over them (programs' windows...) --> your desktop isn't really easily reachable .. thus some dirty UI hacks on some environments such as a "show only the desktop" icon to remove temporally all the windows on top of it... brrr... Anyway. I'm currently working a bit on a Dock app, but this time, not a separate application, but one which also handles the background. The reason was that some things weren't easy to do at all ("highlighting" the place where the user *will* put a stone for example) with a separate window for the Dock, and all in all, having a unique application for handling the background stuff and the dock/panel stuff seems good. From my early tests it seems to be quite useable (speed) and there is a plus, you could do fancy graphical stuffs as you draw on the background directly (transparency, etc.) very easily (thanks to back-art). see http://www.roard.com/screenshots/screenshot_background.png To end with the background thing : for me it mustn't offers the possibility to put your icons files on it, for the reason stated earlier, but you should have the possibility of customizing the background. That is, put an image (classic), but also put things like meteo, last news, etc. (in the same spirit as konfabulator on mac os x or karamba on kde). -- Nicolas Roard |
From: <ceh...@ma...> - 2003-05-12 22:22:44
|
On Monday, May 12, 2003, at 11:34 Pacific/Honolulu, Nicolas Roard wrote: > On 2003-05-12 20:56:18 +0000 ceh...@ma... wrote: > > Hello, > >> I think that a combination of InterfaceWM and a separate Dock.app is >> ideal. I have to say that prefer the OS X style of Dock over the >> OpenStep one. For instance, I think that the user should be able to >> put documents in the dock. I also think that the openstep style of >> having two separate places for App icons is confusing to the typical >> user, they wonder why the can grab an App ion and put *it* into the >> dock, but cannot put a miniwindow icon there as well. Stuff like >> that. >> So, what this means is that if I do write a Dock.app (and it's >> looking like I will), it will be in the basic style os OS X. Now, >> the question remains, what to do with the miniwindows? Do we put >> those in the Dock as well (like OS X), or de we put them in the >> lower part of the screen? > > Imho, the "Dock" should be some separate program, perhaps communicating > with the window manager (IWM ?) to handle iconfied windows ... > So that you could have a program with a NeXT-like dock, or an > Aqua-dock, or > even a panel or whatever. True. > > The "Dock" program (whatever its representation) only needs to receive > startup notification of programs (already the case for gnustep apps), > iconification and close notifications too. Perhaps others > notifications are needed. for iconification, maybe even ask interfaceWm for the window's bitmap, scale it down and make it the mini window icon, OS X style. My goal is not to copy OS X features, just the ones that are "good". Of course, if somebody has better ideas that's even better. > >> Having a dock to handle these types of things will make the creation >> of InterfaceWM much easier since it will be able to defer these >> window handling issues to a dock. There just needs to be a method >> of interaction between InterfaceWM and Dock.app, the natural choice >> would be via Distributed Objects, of course. > > Distributed Notifications would be fine. > >>> - Dock: I think GWorkspace.app includes Backgrounder.app that can >>> take >>> care of the root window and a Fiend where you cand attach >>> applications >>> and switch workspaces. There's also a beta Panel for GNUstep >>> (screenshots here: http://wiki.gnustep.org/index.php/Panel) but IMHO >>> a >>> gnome/kde-like panel is not a good idea for GNUstep. >> Fiend is ok, but is it not everything a real dock can be. I also >> think that these two things should be separate processes. I've >> heard of the Panel and seen the screenshots, but have never seen any >> code?!? I also don't think that a GNOME/windows/KDE style panel is >> good, that is garbage, "Start" menus are garbage. > > Well the code was never officially released, because it lacks some > features > to be really user friendly ... > Anyway the code is downloadable on > http://www.roard.com/download/Panel.tgz > (caution : crappy and unsupported code for the moment) I printed it out and I'm gonna read it on the plane. There is no indication of any license for this code. I may end up using this code or extending it, should i assume it's GPL? > >> Hmmm, Who owns the root window? Good question! In the traditional >> OpenStep, the root window was blank, just a color or whatever. Os X >> allows the placement of icons and such on the desktop, which I find >> very, very, convenient and like. I think that if we allow files to >> be put on the desktop, then GWorkspace should own it. > > In my opinion, putting files on the desktop is *not good*. Well, at > first it sounds like a good idea, but you'll end with your desktop > filled with files quickly. And > the reason why NeXT choose to not let people put their file on the > desktop > is quickly remained : because generally you have *something* over them > (programs' windows...) --> your desktop isn't really easily reachable > .. thus > some dirty UI hacks on some environments such as a "show only the > desktop" > icon to remove temporally all the windows on top of it... brrr... Very true..Maybe there is something better to do with the desktop then, rather than just a place to put a background color or picture? > > Anyway. I'm currently working a bit on a Dock app, but this time, not > a separate application, but one which also handles the background. The > reason > was that some things weren't easy to do at all ("highlighting" the > place where > the user *will* put a stone for example) with a separate window for > the Dock, > and all in all, having a unique application for handling the > background stuff > and the dock/panel stuff seems good. > From my early tests it seems to be quite useable (speed) and there is > a plus, you could do fancy graphical stuffs as you draw on the > background directly (transparency, > etc.) very easily (thanks to back-art). see > http://www.roard.com/screenshots/screenshot_background.png I was thinking of making a version of the dock which is a solid bar across the screen, so I would not have the "ghost" problem you mention. I like your idea though, maybe you can use this type of thing to make the desktop itself a better place (see above)? > > To end with the background thing : for me it mustn't offers the > possibility to put your > icons files on it, for the reason stated earlier, but you should have > the possibility of customizing the background. > That is, put an image (classic), but also put things like meteo, last > news, etc. > (in the same spirit as konfabulator on mac os x or karamba on kde). Hmmm...you're talking about rendering HTML on the desktop. I personally don't like that idea because I find it way too distracting. Windows has this feature and I tried it out once but it drove me nuts looking at it. Also, we don't have GNUstep HTML yet. Is there some other info we can put on the desktop which is not so intruding? Whatever is displayed there, IMHO, it should be non-interactive informational only. Here is a (lame) example: Change the desktop color from red to blue based on CPU activity. Chad > > -- > Nicolas Roard > > _______________________________________________ > LinuxSTEP-General mailing list > Lin...@li... > http://lists.linuxstep.org/mailman/listinfo/linuxstep-general |
From: Nicolas R. <ni...@ro...> - 2003-05-13 01:28:02
|
On 2003-05-12 22:13:53 +0000 ceh...@ma... wrote: >> Well the code was never officially released, because it lacks some features >> to be really user friendly ... >> Anyway the code is downloadable on http://www.roard.com/download/Panel.tgz >> (caution : crappy and unsupported code for the moment) > > I printed it out and I'm gonna read it on the plane. There is no indication of any license for this code. I may end up using this code or extending it, should i assume it's GPL? Yes ... as I said, I never released it officially, thus the lack of licence. But I don't think I will sue you :-)))) Anyway my idea now is to implement a dock.app which manage a background window, and perhaps provides some way to change from a pure NeXT dock to an Afterstep one or a Panel... > Very true..Maybe there is something better to do with the desktop then, rather than just a place to put a background color or picture? Well desktop could be used to "monitor" informations, display it.. I used to have the earth map (with up to date satellite pictures) in my root window for example. > I was thinking of making a version of the dock which is a solid bar across the screen, so I would not have the "ghost" problem you mention. The problem wasn't to draw a ghost icon ... but to /detect/ the position of the mouse with DND while *not yet* on the panel ! without covering the entire screen, it's not possible (or perhaps with window manager cooperation, but frankly I think managing the background window is then preferable) > I like your idea though, maybe you can use this type of thing to make the desktop itself a better place (see above)? > >> >> To end with the background thing : for me it mustn't offers the possibility to put your >> icons files on it, for the reason stated earlier, but you should have the possibility of customizing the background. >> That is, put an image (classic), but also put things like meteo, last news, etc. >> (in the same spirit as konfabulator on mac os x or karamba on kde). > Hmmm...you're talking about rendering HTML on the desktop. I personally Well ... I don't know how konfabulator or karamba manage their drawings (I'm not sure they use HTML on the desktop anyway) but I surely wasn't considered that ... HTML is to rigid and inadapted for what I want (well, classic HTML). I was more on the idea of using some bundles providing NSViews that you could move on your background... for example a bundle drawing the meteo, etc. > don't like that idea because I find it way too distracting. Windows has this feature and I tried it out once but it drove me nuts looking at it. Also, we don't have GNUstep HTML yet. Is there some other info we can put on the desktop which is not so intruding? Whatever is displayed there, IMHO, it should be non-interactive informational only. Here is a (lame) example: Change the desktop color from red to blue based on CPU activity. Yep that's another idea. Anyway this thing isn't my main goal, it's just that, after trying konfabulator on mac os x , I think it's a nice idea, and could be worth implementing it... but it's not for tomorrow, I should first finish the basic Background+Dock.app ;-) The idea behind anyway is the fact that you don't drop icons on your desktop, and the desktop is only used to display nice pictures or perhaps monitoring informations... as I think it would be handled by bundles, people won't be forced to used it that way :) -- Nicolas Roard |
From: <ceh...@ma...> - 2003-05-13 02:30:29
|
On Wednesday, Mar 12, 2003, at 15:27 Pacific/Honolulu, Nicolas Roard wrote: (snip) > >> I was thinking of making a version of the dock which is a solid bar >> across the screen, so I would not have the "ghost" problem you >> mention. > > The problem wasn't to draw a ghost icon ... but to /detect/ the > position of the > mouse with DND while *not yet* on the panel ! without covering the > entire screen, it's not possible (or perhaps with window manager > cooperation, but frankly I think managing the background window is > then preferable) This interest me very much because I'd like to uncover any hurdles i may come across making a Dock.app. I'm wondering, why was it necessary to track the mouse *before* it was on the panel? Also, why were you using XDND, doesn't GNUstep provide more general DnD capabilities? Why us X11 specifics? |
From: Nicolas R. <ni...@ro...> - 2003-05-13 12:13:25
|
On 2003-05-13 02:24:49 +0000 ceh...@ma... wrote: > > On Wednesday, Mar 12, 2003, at 15:27 Pacific/Honolulu, Nicolas Roard wrote: > (snip) >> >>> I was thinking of making a version of the dock which is a solid bar across the screen, so I would not have the "ghost" problem you mention. >> >> The problem wasn't to draw a ghost icon ... but to /detect/ the position of the >> mouse with DND while *not yet* on the panel ! without covering the entire screen, it's not possible (or perhaps with window manager cooperation, but frankly I think managing the background window is then preferable) > This interest me very much because I'd like to uncover any hurdles i may come across making a Dock.app. I'm wondering, why was it necessary to track the mouse *before* it was on the panel? Well with Window Maker, you could take an appicon and dock it. When you do that (i.e. when you are dragging the appicon), the dock "shows" you the future position of your icon on the dock (it draws a "ghost" image of the appicon on the future position). Window Maker starts to do that when you are near (100-200 pixels?) of the dock. Anyway it's just an example. If you have a dock which is only as large as the "stones", you can't detect when someone is trying to dnd something on you, until it is effectively upon your dock. So the idea is to have a window a bit larger than the stones, with perhaps a transparent part, for doing that. But, it's not a very good solution... for example, one cool thing with the Window Maker dock is that you could easily move it on the other side of the screen, just in clicking on the first "stone" and dragging it on the left (or right). Before effectively moving, the dock is shown as a ghost on its future emplacement. It's not possible to do that if the dock isn't in fact in a window with the screen size. Anyway ... it's quite simple to do a Dock simply in its non-shaped window; but what I'd like to do is to have the same behavior as the WindowMaker's dock, because it enhance the usuability in my opinion; it's not only some nice graphicals stuffs... And moreover, having the entire screen simplify many things (if I'd like to add shelves in tabs auto-hidded on the edge of the screens ala slicker, or change to a panel, etc.) > Also, why were you using XDND, doesn't GNUstep provide more general DnD capabilities? Why us X11 specifics? I wasn't speaking of XDND at all, but DND in general (and via GNUstep mechanisms of course) -- Nicolas Roard |
From: Jim B. <ba...@ma...> - 2003-05-12 21:53:27
|
On Monday, May 12, 2003, at 04:56 PM, ceh...@ma... wrote: > On Monday, May 12, 2003, at 08:33 Pacific/Honolulu, Ernest Frigola > wrote: > >> >> For me it's not clear the rule of these applications in the GNUstep >> environment. Should the Workspace Manager (GWorkspace.app) take care >> of >> the root window/desktop instead of the window manager? is this >> documented somewhere? is somebody working in this? > > Hmmm, Who owns the root window? Good question! In the traditional > OpenStep, the root window was blank, just a color or whatever. Os X > allows the placement of icons and such on the desktop, which I find > very, very, convenient and like. I think that if we allow files to be > put on the desktop, then GWorkspace should own it. In OS X 10.1, if you quit the Finder, the desktop picture would disappear, leaving you with a generic blue root window. Now, in 10.2, the desktop picture is managed independently of the Finder, and I suppose the files that appear to be on the desktop are shown in some kind of transparent window covering the whole root window. This is nice, because now you can quit the Finder, and use some other file manager if you want and still have a desktop picture. I just want to point this out because I think it was an improvement for OS X. GWorkspace already has an option to use the desktop or not, but if one is not using the desktop, there should be a facility in the system for setting a desktop image (currently WindowMaker does this for me, and I guess this could be the window manager's responsibility in future GNUstep-oriented systems). - Jim |
From: <ceh...@ma...> - 2003-05-12 22:32:40
|
On Monday, May 12, 2003, at 11:53 Pacific/Honolulu, Jim Balhoff wrote: > On Monday, May 12, 2003, at 04:56 PM, ceh...@ma... wrote: > >> On Monday, May 12, 2003, at 08:33 Pacific/Honolulu, Ernest Frigola >> wrote: >> >>> >>> For me it's not clear the rule of these applications in the GNUstep >>> environment. Should the Workspace Manager (GWorkspace.app) take care >>> of >>> the root window/desktop instead of the window manager? is this >>> documented somewhere? is somebody working in this? >> >> Hmmm, Who owns the root window? Good question! In the traditional >> OpenStep, the root window was blank, just a color or whatever. Os X >> allows the placement of icons and such on the desktop, which I find >> very, very, convenient and like. I think that if we allow files to >> be put on the desktop, then GWorkspace should own it. > > In OS X 10.1, if you quit the Finder, the desktop picture would > disappear, leaving you with a generic blue root window. Now, in 10.2, > the desktop picture is managed independently of the Finder, and I > suppose the files that appear to be on the desktop are shown in some > kind of transparent window covering the whole root window. This is > nice, because now you can quit the Finder, and use some other file > manager if you want and still have a desktop picture. I just want to > point this out because I think it was an improvement for OS X. > GWorkspace already has an option to use the desktop or not, but if one > is not using the desktop, there should be a facility in the system for > setting a desktop image (currently WindowMaker does this for me, and I > guess this could be the window manager's responsibility in future > GNUstep-oriented systems). Hmm, Since actually drawing the background is X11 dependent (right?, the gnustep backends don't handle this, right?), then perhaps InterfaceWM should handle it. The actual user interface for setting it should be a separate thing though, perhaps a Preferences.app bundle. BTW. The reason why I'm CC these messages to linuxstep and interfacewm mailing list is because this topic is applicable to all of us, if this is not ok, please say.. If I do write (or extend) this Dock.app, there will have to cooperation with interfacewm development to get it right. We need to discuss and agree on how to do the DO messaging. I have not looked at interfacewm code for a few months, is there any DO code in it right now which handles this stuff? Chad > > - Jim > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise > solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Interfacewm-discuss mailing list > Int...@li... > https://lists.sourceforge.net/lists/listinfo/interfacewm-discuss |
From: Chris B. V. <ch...@we...> - 2003-05-12 22:45:24
|
On Mon, 12 May 2003 10:56:18 -1000 ceh...@ma... wrote: [...] > > IMHO the pieces are available but they need more integration: > > - Window manager: Interface window manager > > Jewell Objective-C (http://mjr.towers.org.uk/xwinman.html) > > - Workspace manager: GWorkspace.app > Both good, not familiar with jewell though, it's written in objc but > does it uses GNUstep frameworks? Jewel is written in C++. Work on Jewel in ObjC has just started, but source is not (yet) available. That said, here's my 0.02 Dollar, Euro, Rubel, Pesos, Whatever: IMHO, for a good integration of a desktop (keeping in mind that we currently are dependent of X11, which could change if someone was going to write an appropriate backend) we need two tools (or applications) - a window manager - a desktop manager (which may consist of several parts/bundles) To merge both in one tool is feasible, but should not be considered. For one, it will make the whole thing too big to support (the source) in a simple way. As for an (abstract) overview of what those two are supposed to do, a) The window manager does exactly that -- managing windows. Nothing more, nothing less. That is: open, close, move, resize, hide, show. And that's it. The window manager is in control of how to display objects on your screen(s). And yes, application icons are windows and therefor fall under the window manager's job. b) The desktop manager is in charge of the Dock and (if applicable) a Fiend and/or Panel. (I see the Dock as a static and "slimmed down" version of the Fiend, the latter being freely movable across the screen). It is also in charge of launching applications, eg. from a file browser or setting the background image. Basically, it does what (G)Workspace already offers. So in a nutshell, you have a minimalistic window manager, that does nothing on it's own. It's full "potential" can only be experienced in conjunction with a/the desktop manager, since it doesn't offer any conveniences like a background menu *gasp* and therefor neither a way to launch applications, nor even a way to exit the thing... As I said above, it only manages windows. *bummer* How do I think this will work? Easy -- the combination of both is launched in reverse, you first start the desktop manager (which DOES have background menus) and then start the window manager. Therefor, exiting the desktop manager exits the window manager. Now, as to the Dock, as said above, it should be static on your screen. Eg. it can only be moved to and within predefined areas, like left or right screen side. To add an application, you drag its icon from a file browser onto it, similar to as it is done with Window Maker and the Fiend in GWorkspace. The difference here is, that, when you launch an application from the Dock, the application icon WILL be displayed at the bottom of the screen (as this is the window managers responsibility) That way, even if your main screen area is cluttered, you can see which applications are running and can easily move one in front by clicking the respective app-icon. (WMaker will not display the app-icon, if the app is docked). I haven't thought much about how a Panel would apply here, but a quick idea would be that the window manager will send a notification to the desktop manager everytime an application is launched. If a Panel is in use, the desktop manager adds the app-icon to a special tab, called say "Running", and sends a note back to the window manager, not do display the app-icon. Of course, the reverse applies, when the application is closed. As I said, just my 0.02 and not much thought through, though, but I'm fairly sure that the first part(s) can easily be implemented. On a side note: I start my X11 sessions by launching GWorkspace first, then the actual window manager -- install wmaker with --enable-lite and try for yourself for a more NeXT'ish experience ;-) -- Chris |
From: <ceh...@ma...> - 2003-05-12 23:35:37
|
On Monday, May 12, 2003, at 12:45 Pacific/Honolulu, Chris B. Vetter wrote: > On Mon, 12 May 2003 10:56:18 -1000 > ceh...@ma... wrote: > [...] >>> IMHO the pieces are available but they need more integration: >>> - Window manager: Interface window manager >>> Jewell Objective-C (http://mjr.towers.org.uk/xwinman.html) >>> - Workspace manager: GWorkspace.app >> Both good, not familiar with jewell though, it's written in objc but >> does it uses GNUstep frameworks? > > Jewel is written in C++. Work on Jewel in ObjC has just started, but > source is not (yet) available. Ok, I'll keep an eye out for it then. > > > That said, here's my 0.02 Dollar, Euro, Rubel, Pesos, Whatever: > > IMHO, for a good integration of a desktop (keeping in mind that we > currently are dependent of X11, which could change if someone was going > to write an appropriate backend) we need two tools (or applications) > > - a window manager > - a desktop manager (which may consist of several parts/bundles) > > To merge both in one tool is feasible, but should not be considered. > For > one, it will make the whole thing too big to support (the source) in > a simple way. > > As for an (abstract) overview of what those two are supposed to do, > > a) The window manager does exactly that -- managing windows. Nothing > more, nothing less. That is: open, close, move, resize, hide, show. > And that's it. The window manager is in control of how to display > objects on your screen(s). And yes, application icons are windows and > therefor fall under the window manager's job. This seems to be very close to what InterfaceWM is. B delegating the other traditional X11 window manager responsibilities to a Dock.app would make their work much easier. > > b) The desktop manager is in charge of the Dock and (if applicable) a > Fiend and/or Panel. (I see the Dock as a static and "slimmed down" > version of the Fiend, the latter being freely movable across the > screen). It is also in charge of launching applications, eg. from a > file > browser or setting the background image. > Basically, it does what (G)Workspace already offers. Doesn't the gnustep API itself handle the launching of apps, why shift this to the Dock? IMHO, the Dock should provide tiles to allow the user to launch the apps, nothing else. It also listens for new apps launching and puts in appropriate tiles. Maybe I'm missing something in your comment..? > > > So in a nutshell, you have a minimalistic window manager, that does > nothing on it's own. It's full "potential" can only be experienced in > conjunction with a/the desktop manager, since it doesn't offer any > conveniences like a background menu *gasp* > and therefor neither a way to > launch applications, nor even a way to exit the thing... As I said > above, it only manages windows. I agree 100% > > *bummer* > > How do I think this will work? > Easy -- the combination of both is launched in reverse, you first start > the desktop manager (which DOES have background menus) and then start > the window manager. Therefor, exiting the desktop manager exits the > window manager. Cool, is the desktop manager also handling session management, or should that be another thing? > > Now, as to the Dock, as said above, it should be static on your screen. > Eg. it can only be moved to and within predefined areas, like left or > right screen side. To add an application, you drag its icon from a file > browser onto it, similar to as it is done with Window Maker and the > Fiend in GWorkspace. Right, the fiend could still be used if people prefer it. > The difference here is, that, when you launch an application from the > Dock, the application icon WILL be displayed at the bottom of the > screen (as this is the window managers responsibility) I think it;s confusing to most users to have app icons in two different places. i think they should only appear in one place, the Dock. Comments? > That way, even if > your main screen area is cluttered, you can see which applications are > running and can easily move one in front by clicking the respective > app-icon. (WMaker will not display the app-icon, if the app is docked). s.a > > I haven't thought much about how a Panel would apply here, but a quick > idea would be that the window manager will send a notification to the > desktop manager everytime an application is launched. If a Panel is in > use, the desktop manager adds the app-icon to a special tab, called say > "Running", and sends a note back to the window manager, not do display > the app-icon. Of course, the reverse applies, when the application is > closed. Right, but, in your definition, what is the difference between a Panel and a Dock? > > As I said, just my 0.02 and not much thought through, though, but I'm > fairly sure that the first part(s) can easily be implemented. Right on, this is exactly the kind of conversation I like to see. Can't build without collaboration! > > On a side note: I start my X11 sessions by launching GWorkspace first, > then the actual window manager -- install wmaker with --enable-lite and > try for yourself for a more NeXT'ish experience ;-) > I can't get WindowMaker to compile with --enable-lite (the cvs version), do you have any tips for this? Chad > -- > Chris > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise > solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |
From: Chris B. V. <cb...@kn...> - 2003-05-13 00:07:54
|
On Mon, 12 May 2003 13:27:34 -1000 ceh...@ma... wrote: > On Monday, May 12, 2003, at 12:45 Pacific/Honolulu, Chris B. Vetter > wrote: [...] > > b) The desktop manager is in charge of the Dock and (if applicable) > > a Fiend and/or Panel. (I see the Dock as a static and "slimmed down" > > version of the Fiend, the latter being freely movable across the > > screen). It is also in charge of launching applications, eg. from a > > file browser or setting the background image. > > Basically, it does what (G)Workspace already offers. > Doesn't the gnustep API itself handle the launching of apps, why shift > this to the Dock? IMHO, the Dock should provide tiles to allow the > user to launch the apps, nothing else. It also listens for new apps > launching and puts in appropriate tiles. Maybe I'm missing something > in your comment..? Yes, GNUstep's API has all that is necessary to launch an example. What I meant is, that the desktop manager (FileBrowser, Panel, Dock, What Have You) will _launch_ an application (how is a different issue) when you click its respective app-icon -- while the window manager will _display_ it (create the window and frames, and pop it to the screen) > > How do I think this will work? > > Easy -- the combination of both is launched in reverse, you first > > start the desktop manager (which DOES have background menus) and > > then start the window manager. Therefor, exiting the desktop manager > > exits the window manager. > Cool, is the desktop manager also handling session management, or > should that be another thing? Since the "session" data consists of the applications currently running, IMHO this should be implemented on a desktop manager level (or somewhere between window and desktop manager). A minor problem here would be that the window manager needs to get the information on where the windows of the applications were last placed on the screen, eg. which screen. GNUstep already stores some of that information, eg. menu position, in NSUserDefaults, so there already is a starting point for that. OTOH, you can interpret "session" simply as "window A is at X1 x Y1" and "window B is at X2 x Y2". Upon start, the window manager reads a setting (an array) in NSUserDefaults (set by the desktop manager upon logoff) that contains all currently running applications and instructs the desktop manager to launch the applications found in that array. All you would need to add is some information as to which screen the app needs to go to, as X and Y is already stored. However, keep in mind that GNUstep has some issues with multiple screens, eg. it does not support windows split across two screens (see gui/Source/NSWindow.m) > > The difference here is, that, when you launch an application from > > the Dock, the application icon WILL be displayed at the bottom of > > the screen (as this is the window managers responsibility) > I think it;s confusing to most users to have app icons in two > different places. i think they should only appear in one place, the > Dock. Comments? If I'm running WMaker, I usually have several virtual screens, one per (large) application, eg browser, mail, code editing, Gorm, ... I launch those from WMaker's Dock, so I do not get an app-icon -- which always annoys the heck out of me if I need to quickly switch to a specific application, but can't. Instead I have to flip through all screens until I reach the one that has the application I want to go to. > > That way, even if > > your main screen area is cluttered, you can see which applications > > are running and can easily move one in front by clicking the > > respective app-icon. (WMaker will not display the app-icon, if the > > app is docked). > s.a Indeed ;-) Having app-icons at the bottom makes switching screens much easier. > Right, but, in your definition, what is the difference between a Panel > and a Dock? Essentially it would be the same from a usability point of view. Both give quick access to applications. The difference is, that a Dock is one-dimensional (only offering a row of icons) while a Fiend and Panel are multi-dimensional. You can "dock" an icon on either side of the Fiend, and the Panel uses tabs instead. In that way, a Panel is comparable to Afterstep's collapsing Dock "folders". > > On a side note: I start my X11 sessions by launching GWorkspace > > first, then the actual window manager -- install wmaker with > > --enable-lite and try for yourself for a more NeXT'ish experience > I can't get WindowMaker to compile with --enable-lite (the cvs > version), do you have any tips for this? I can't get WMaker to compile from CVS at all, so the only tip would be not to use CVS ;-) Sorry. -- Chris |
From: Ernest F. <bu...@er...> - 2003-05-12 22:46:25
|
-- On Mon, 12 May 2003 10:56:18 -1000 ceh...@ma... wrote: > So, what this means is that if I do write a Dock.app (and it's looking > > like I will), it will be in the basic style os OS X. It's no the same that a Dock.app but I find very interesting the development of the slicker project for KDE (http://slicker.sf.net). Before releasing anything they have documented (http://slicker.sourceforge.net/docs.php) and designed (http://slicker.sourceforge.net/screen-mockups.php) what they are trying to build. Very uncommon in the open source projects ;) > Now, the question > remains, what to do with the miniwindows? Do we put those in the Dock > > as well (like OS X), or de we put them in the lower part of the > screen?(...) > Fiend is ok, but is it not everything a real dock can be. I also > think that these two things should be separate processes. I've heard > of the (...) > Hmmm, Who owns the root window? Good question! In the traditional > OpenStep, the root window was blank, just a color or whatever. Os X A lot of decisions to make. IMHO a lot of consens is needed here between the GNUstep developers if we want to join forces and minimize duplication of efforts and avoid cruft (TM) (http://mpt.phrasewise.com/stories/storyReader$374): 1) What application takes care of the root window? 2) What are exactly the functionalities of the Apps controling the user environment (Workspace Manager, Dock, Window Manager,...) 3) Can the user save files in the desktop? 4) Can the user put files in the Dock? 5) Who's developing every part? 6) ... I know it's possible to build an environment that supports all the possibilities, but I feel that this will take GNUstep to the same path that KDE or Gnome. -- Ernest |