Thread: RE: [Interfacewm-discuss] Re: [Simplygnustep-discuss] GSDock and interfacewm interaction
Status: Alpha
Brought to you by:
cehardin
From: Mondragon, I. <ian...@ba...> - 2003-06-04 14:58:04
|
Chad, I'm actually in the proccess of setting up the Notifications for IWM for exactly this purpose, with all pertinent data being stored in the userInfo dictionary. Chris Vetter and I have also been discussing the reorganization of the source & layout of the build, which has resulted in a couple of IWM libraries that will allow developers to hook into the code in order to make an IWMComponent (i.e. libIWMComponent). There is still some work to be done, but as there appears to be a need, I will commit the preliminary code this week. As a side note, when the code is available, the notification names will be available in IWMNotifications.[hm]. - Ian -----Original Message----- From: Chad Hardin [mailto:ceh...@ma...] Sent: Wednesday, June 04, 2003 5:30 PM Cc: int...@li...; sim...@so... Subject: [Interfacewm-discuss] Re: [Simplygnustep-discuss] GSDock and interfacewm interaction #3 should say the "Title" of the window, not the "Tile" hehe Chad Chad Hardin wrote: > As you may know I am making a Dock.app for gnustep. > > It's a bit of a hybrid between the next stle and the OS X style of dock. > > How is it like next? It has tiles and is on the right edge of the > screen. > How is it like OS X? It is centered on the right edge and grows as > things are added to it. It also shrinks to take in more icons. The > plan is also to automatically "swallow" all App Tiles. I would alos > like to put miniwindows in it as well > > Anyhow, I'm gonna need some interaction with interfacewm. For > example, I'm gonna need to be able to know when windows are to be > minimized as well as other information. > > I would like to keep all X11 specific stuff out of GSDock.app. Soo... > I would need interfacewm to tell me, (via > NSDistributedNotificationCenter?) that a window is to minimized along > with: > > 1. An NSImage of the windows contents, preferebly smoothly scaled to > no larger than 64x64. > 2. A non X11 way of identifying the window. > 3. The tile of the window > 4. The pid of the application which owns the window (maybe not necc) > 5. Probably a few more things. > > Anyhow, this would make interfacewm a bit easier to develop since all > it would have to do is hide the window and pump out a notification. > Likewise, when a window is to be unminimized, i would just tell > interfacewm to display it. > > Are you guys interested in working together on this? > > Thanks! > > Chad > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Interfacewm-discuss mailing list Int...@li... https://lists.sourceforge.net/lists/listinfo/interfacewm-discuss |
From: Mondragon, I. <ian...@ba...> - 2003-06-04 19:00:02
|
chad, the client's unique id, mainly. here's a theoretical example using the typical dock example. --- IWM's responsibilities --- 1. you open an xterm, which creates a new IWM client 2. this generates a notification of the new client's existance for anything listening 3. the userInfo dictionary posted along with this notification would contain a reference to the unique id of the client, and also anything else that could be pertinent (icon image data, etc.) --- dock's responsibilities --- 4. the dock is an IWMComponent & is actively listening for a variety of notifications, including the one just created by the new client 5. the dock recieves the notification & it's associated userInfo dictionary, which identifies the client & gives us a reference to the image to use for the dock's icon representing this client 6. this is all that is now needed in order to interact with/control the client; you can now post a variety of notifications using this information directly from your component, with no need to hook into other IWM libs. for example: - post IWMClientCloseNotification, along with the client's id in the userInfo dictionary. * IWM will close the client, if possible - post IWMClientMoveNotification, along with the client's id, X and Y coordinates in the userInfo dictionary. * IWM will move the client to the specified coordinates, if possible you get the idea... - ian -----Original Message----- > I'm actually in the proccess of setting up the Notifications for IWM for >exactly this purpose, > Awesome! > with all pertinent data being stored in the userInfo >dictionary. > I'm not following here, what pertinent info? Is this information related to basic windowing interactions? |
From: Chad H. <ceh...@ma...> - 2003-06-04 19:17:47
|
Mondragon, Ian wrote: >chad, > > the client's unique id, mainly. here's a theoretical example using the >typical dock example. > >--- IWM's responsibilities --- > >1. you open an xterm, which creates a new IWM client >2. this generates a notification of the new client's existance for anything >listening >3. the userInfo dictionary posted along with this notification would contain >a reference to the unique id of the client, and also anything else that >could be pertinent (icon image data, etc.) > Ahh, I see, we're thinking along two different lines here. I was only thinking of how to handle GNUstep apps, as such, I would use NSWorkspace notifications for detecting when apps where launching. To detect non-gnustep X11 apps, I could use your methods too. > >--- dock's responsibilities --- > >4. the dock is an IWMComponent & is actively listening for a variety of >notifications, including the one just created by the new client > When you say IWMomponent you mean an object within the process of interfacewm? I'm making the dock as a completely separate process. I'm thinking more along the lines of an NSDistributedNotificationCenter, is that your plan as well? Chad >5. the dock recieves the notification & it's associated userInfo dictionary, >which identifies the client & gives us a reference to the image to use for >the dock's icon representing this client >6. this is all that is now needed in order to interact with/control the >client; you can now post a variety of notifications using this information >directly from your component, with no need to hook into other IWM libs. for >example: > > - post IWMClientCloseNotification, along with the client's id in the >userInfo dictionary. > * IWM will close the client, if possible > - post IWMClientMoveNotification, along with the client's id, X and Y >coordinates in the userInfo dictionary. > * IWM will move the client to the specified coordinates, if possible > >you get the idea... > >- ian > > >-----Original Message----- > > >> I'm actually in the proccess of setting up the Notifications for IWM for >>exactly this purpose, >> >> >> > >Awesome! > > > >>with all pertinent data being stored in the userInfo >>dictionary. >> >> >> >I'm not following here, what pertinent info? Is this information >related to basic windowing interactions? > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The best >thread debugger on the planet. Designed with thread debugging features >you've never dreamed of, try TotalView 6 free at www.etnus.com. >_______________________________________________ >Simplygnustep-discuss mailing list >Sim...@li... >https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss > > |
From: Chris B. V. <ch...@we...> - 2003-06-04 19:40:49
|
On Wed, 04 Jun 2003 13:58:04 -0500 "Mondragon, Ian" <ian...@ba...> wrote: [...] > 4. the dock is an IWMComponent & is actively listening for a variety > of notifications, including the one just created by the new client > 5. the dock recieves the notification & it's associated userInfo > dictionary, which identifies the client & gives us a reference to the > image to use for the dock's icon representing this client > 6. this is all that is now needed in order to interact with/control > the client; you can now post a variety of notifications using this > information directly from your component, with no need to hook into > other IWM libs. for example: There are two problems I can see that may arise here ... a) there may be two (or more) components that will 'fight' for the notification (well, not for the notification per se, but who's gonna handle it). Eg. you have a Dock and a Panel and both want to display the appicon. b) As it is right now (to my knowledge) there's no way you can "capture" and "highjack" the appicon and and prevent GNUstep from _not_ displaying it at the bottom of your screen anyway. According to Documentation/Foundation/DefaultsSummary.html this is what GSAppOwnsMiniwindow and UseWindowMakerIcons are supposed to offer, but it doesn't seem to work. In case you don't have the docu at hand, here's what it says: GSAppOwnsMiniwindow A boolean value which defaults to YES. Some window managers control the miniaturized versions of windows themselves. Set this default to NO to let the window manager have it's way, otherwise, GNUstep will create a miniwindow. UseWindowMakerIcons A boolean value which defaults to YES. If set to YES then icon windows are controlled by the window manager, otherwise they are controlled by the GNUstep application. I've tested each alone and both together, with about 8 or 10 different window managers, and the result was always the same: GNUstep _always_ displayed the appicon. How do I know? Some of the WMs I've tested put window decorations around X11 appicons, yet, GNUstep-based apps' had none. Others sorted appicons similar to Window Maker, yet GNUstep appicons _always_ appeared at 0,0(the lower left corner) That is, appicons for eg. Ink and Terminal got "stacked" on top of the other. -- Chris |
From: Chad H. <ceh...@ma...> - 2003-06-05 00:13:23
|
Chris B. Vetter wrote: >On Wed, 04 Jun 2003 13:58:04 -0500 >"Mondragon, Ian" <ian...@ba...> wrote: >[...] > > >>4. the dock is an IWMComponent & is actively listening for a variety >>of notifications, including the one just created by the new client >>5. the dock recieves the notification & it's associated userInfo >>dictionary, which identifies the client & gives us a reference to the >>image to use for the dock's icon representing this client >>6. this is all that is now needed in order to interact with/control >>the client; you can now post a variety of notifications using this >>information directly from your component, with no need to hook into >>other IWM libs. for example: >> >> > >There are two problems I can see that may arise here ... > >a) there may be two (or more) components that will 'fight' for the > notification (well, not for the notification per se, but who's gonna > handle it). Eg. you have a Dock and a Panel and both want to display > the appicon. > Maybe they can be made to cooexist? or maybe some type of mutual exclusion for who will provide such a thing (whoever asks first)? > >b) As it is right now (to my knowledge) there's no way you can "capture" > and "highjack" the appicon and and prevent GNUstep from _not_ > displaying it at the bottom of your screen anyway. > > According to Documentation/Foundation/DefaultsSummary.html this is > what GSAppOwnsMiniwindow and UseWindowMakerIcons are supposed to > offer, but it doesn't seem to work. > I'm gonna peek at the gnustep sources and see what's up here. > > In case you don't have the docu at hand, here's what it says: > > GSAppOwnsMiniwindow > > A boolean value which defaults to YES. Some window managers > control the miniaturized versions of windows themselves. Set > this default to NO to let the window manager have it's way, > otherwise, GNUstep will create a miniwindow. > > > UseWindowMakerIcons > > A boolean value which defaults to YES. If set to YES then icon > windows are controlled by the window manager, otherwise they are > controlled by the GNUstep application. > >I've tested each alone and both together, with about 8 or 10 different >window managers, and the result was always the same: GNUstep _always_ >displayed the appicon. >How do I know? >Some of the WMs I've tested put window decorations around X11 appicons, >yet, GNUstep-based apps' had none. >Others sorted appicons similar to Window Maker, yet GNUstep appicons >_always_ appeared at 0,0(the lower left corner) That is, appicons for >eg. Ink and Terminal got "stacked" on top of the other. > > > |
From: Chris B. V. <ch...@we...> - 2003-06-05 01:04:48
|
On Thu, 05 Jun 2003 09:56:50 -0700 Chad Hardin <ceh...@ma...> wrote: > >There are two problems I can see that may arise here ... > >a) there may be two (or more) components that will 'fight' for the > > notification (well, not for the notification per se, but who's > > gonna handle it). Eg. you have a Dock and a Panel and both want to > > display the appicon. > Maybe they can be made to cooexist? or maybe some type of mutual > exclusion for who will provide such a thing (whoever asks first)? I agree that this may be more of a cosmetic "problem" and it probably won't hurt to have said icon in a panel and the dock, but you never know what ideas people may come up with... ;-) -- Chris |
From: Chad H. <ceh...@ma...> - 2003-06-05 00:35:07
|
After looking through the gnustep sources, NSApplication.m specifically, I found no checks as to whether the AppIcon will or will not be created. It just does it. Chad > >> >> b) As it is right now (to my knowledge) there's no way you can "capture" >> and "highjack" the appicon and and prevent GNUstep from _not_ >> displaying it at the bottom of your screen anyway. >> >> According to Documentation/Foundation/DefaultsSummary.html this is >> what GSAppOwnsMiniwindow and UseWindowMakerIcons are supposed to >> offer, but it doesn't seem to work. >> > > I'm gonna peek at the gnustep sources and see what's up here. > > |
From: Chris B. V. <ch...@we...> - 2003-06-05 01:29:56
|
On Thu, 05 Jun 2003 10:18:46 -0700 Chad Hardin <ceh...@ma...> wrote: > After looking through the gnustep sources, NSApplication.m > specifically, I found no checks as to whether the AppIcon will or will > not be created. It just does it. You can't find it in -gui because it's handled in -back ;-) In Source/x11/XGServerWindow.m to be more specific. -- Chris |
From: Mondragon, I. <ian...@ba...> - 2003-06-04 19:34:06
|
chad, therein lies the host of other problems. in order to keep IWM proper as minimal as possible, we're trying to provide developers with a standard way of extending it's functionality via IWMComponents. these, in theory, are loaded in as bundles - the current IWMComponent/IWMComponentManager code in CVS is very incomplete, and what is there is nasty and scary. part of the problem is determining what functionality should/should not be present, given the high-level nature of the concept. while your project is being developed as a standalone application, separate from all other things, this is entirely your perogative & choice (obviously). in the small, IWM-biased world of Ian (that's the one i live in), i see the opportunity to create the 2nd most usable IWMComponent...the first being a RootMenu.iwmcomponent, ala WindowMaker's menu. given that it plays an integral part in the user's interaction with the wm and the desktop environment as a whole, i see the partial integration with IWM as a benefit. how it all ties in is still kind of fuzzy... there are definitely several options here, but we're trying to figure out the best approach from IWM's point of view in the picture... - ian -----Original Message----- >--- IWM's responsibilities --- > >1. you open an xterm, which creates a new IWM client >2. this generates a notification of the new client's existance for anything >listening >3. the userInfo dictionary posted along with this notification would contain >a reference to the unique id of the client, and also anything else that >could be pertinent (icon image data, etc.) > Ahh, I see, we're thinking along two different lines here. I was only thinking of how to handle GNUstep apps, as such, I would use NSWorkspace notifications for detecting when apps where launching. To detect non-gnustep X11 apps, I could use your methods too. > >--- dock's responsibilities --- > >4. the dock is an IWMComponent & is actively listening for a variety of >notifications, including the one just created by the new client > When you say IWMomponent you mean an object within the process of interfacewm? I'm making the dock as a completely separate process. I'm thinking more along the lines of an NSDistributedNotificationCenter, is that your plan as well? |
From: Chad H. <ceh...@ma...> - 2003-06-05 00:10:11
|
Hi Ian, thanks for the reply. Ok, so we are currently differing on this point: I think that it would be best to keep each component (such as the wm and the dock) as standalone apps, which do their prescribed function and that's it. You are thinking that IWM should be very extensible so that it can take on many different tasks, such as a Dock. I am along the lines of using a very minimalist window manager that relies on separate apps to do other things. This would mean using gnustep distributed *whatever* for communications. Also, my thinking would place much less emphasis of extending the window manager via bundles. This is obviously totally opposite of what interfacewm is going towards (yes?). However, let me ask you this. How feasible is it to write an X11 window manager, such as interfacewm, that can do gnustep distributed stuff, considering that you would not be running the traditional gnustep event loop type setup. If this is not really feasible, then hopes of imy dock interacting with an X11 window manager (such as interfacewm) are groundless. But if it is possible, are you open to the idea of moving away from your ideas of a component based interfacewm to a distributed communications/separate apps idea? Possible X11 and gnustep event loop complications aside, I think that my ideas would make the development of interfacewm much easier and faster. Thoughts? Chad Mondragon, Ian wrote: >chad, > > therein lies the host of other problems. in order to keep IWM proper as >minimal as possible, we're trying to provide developers with a standard way >of extending it's functionality via IWMComponents. these, in theory, are >loaded in as bundles - the current IWMComponent/IWMComponentManager code in >CVS is very incomplete, and what is there is nasty and scary. part of the >problem is determining what functionality should/should not be present, >given the high-level nature of the concept. > > while your project is being developed as a standalone application, >separate from all other things, this is entirely your perogative & choice >(obviously). in the small, IWM-biased world of Ian (that's the one i live >in), i see the opportunity to create the 2nd most usable IWMComponent...the >first being a RootMenu.iwmcomponent, ala WindowMaker's menu. given that it >plays an integral part in the user's interaction with the wm and the desktop >environment as a whole, i see the partial integration with IWM as a benefit. >how it all ties in is still kind of fuzzy... > > there are definitely several options here, but we're trying to figure out >the best approach from IWM's point of view in the picture... > >- ian > |
From: Mondragon, I. <ian...@ba...> - 2003-06-05 16:04:01
|
chad, (couple of responses here) chris is right in his understanding of the IWMComponent situation as he describes it below: -----Original Message----- From: Chris B. Vetter [mailto:ch...@we...] However I guess there's a slight misunderstanding in what the components are supposed to be. As I see it (and granted, I may be terribly wrong) the components represent a 'hook' into the window manager. They can be used to either create a bundle that's loaded by iwm directly, or you can use a (one or more?) protocol(s) to create a seperate app that will be able to communicate with iwm. --- snip --- the protocol issue is somewhat questionable these days - but that was a plan at one point. i was working on the IWMComponent code last night & remembered why it was such a barren landscape: because that's the only way it should be. i'm still chewing the component cud at the moment, but the whole grounds for having them was to allow additional utilities to be loadable as some sort of bundle, whether that component works behind the scenes, or has a graphical representation that the user interacts with, such as your dock. please note that the IWMComponents will NOT be subclasses of NSBundle, but wrappers *around* bundles which will allow dynamic re-loading of the code (not ready at this very moment in cvs, though). don't want the dock there anymore? close the thing. just pulled down a newer version of that nifty email notification component? close it, install the new one, reload it. sounds elementary, because it is - but it's the little things that matter the most...and if you're *developing* the component, you'll defintely appreciate not having to restart the window manager. >Ok, so we are currently differing on this point: >I think that it would be best to keep each component (such as the wm and >the dock) as standalone apps, which do their prescribed function and >that's it. but how are you going to access the list of clients that aren't gnustep apps if you have no open line of communication with the window manager? this could lead to some ugliness on par with what chris has been talking about with the GS app icons... i completely agree with the minimalist/traditional unix-style thinking of "one tool, one job"...but i've discovered that this is very tough ground in window manager land. the window manager should be just that: a manager of windows only. but then you have to deal with the fact that people like the ability to work without too much effort - this creates the need for things like a dock, a taskbar, a root window menu, etc.: things that aren't neccessarily part of the window manager's job, but are related to it in a fundamental way. this is where components will (hopefully) come to the rescue. they won't allow you to muck with the guts of IWM, but they'll let you get access to the information you need - such as a list of client names for a menu, or a way to send a move/resize/close request to a particular client. >However, let me ask you this. How feasible is it to write an X11 >window manager, such as interfacewm, that can do gnustep distributed >stuff, considering that you would not be running the traditional gnustep >event loop type setup. If this is not really feasible, then hopes of >imy dock interacting with an X11 window manager (such as interfacewm) >are groundless. But if it is possible, are you open to the idea of >moving away from your ideas of a component based interfacewm to a >distributed communications/separate apps idea? i have had a plethora of discussions on the notification vs. DO topic with people in the gnustep/interfacewm community - and we've all come to the conclusion that notifications were the way to go, for various reasons. first of all, it's much more light-weight - not much code is needed at all. second, i really don't want a distributed object in the code that someone could take advantage of for whatever purpose (i.e. killing any client with the name "xterm" or the window manager itself whenever <whatever> happens). with notifications, you can listen if you want, you can recieve notifications, and you can ignore the notifications you do recieve if you want. and if you only need to listen for two notifications, that makes your life even easier...as opposed to having to set up your component to deal with DO. i don't think your hopes of your dock interacting with IWM are groundless at all - in fact, i *know* they aren't. but, to be brutally honest, i don't think *anybody* would want to use it if it *only* handles gnustep apps - if not because of that limitation, then becuase there simply aren't enough gnustep apps out there to allow you to do everything you need to on a daily basis (generally speaking). i know this is kind of a pain in the ass because (a) you've seem to have already started your dock, (b) the component code isn't complete, (c) the IWM line of thought is somewhat contradictory to how you've plotted out how the dock would work, and (d) IWM isn't 100% done yet...but i know that this stuff will be very feasable, and when everything is worked out, it will make it significantly easier for you (and anyone else) to hook into IWM for similar purposes. - ian |
From: Chad H. <ceh...@ma...> - 2003-06-04 18:25:12
|
Mondragon, Ian wrote: >Chad, > > I'm actually in the proccess of setting up the Notifications for IWM for >exactly this purpose, > Awesome! > with all pertinent data being stored in the userInfo >dictionary. > I'm not following here, what pertinent info? Is this information related to basic windowing interactions? > Chris Vetter and I have also been discussing the reorganization >of the source & layout of the build, which has resulted in a couple of IWM >libraries that will allow developers to hook into the code in order to make >an IWMComponent (i.e. libIWMComponent). > Cool, what types of components did you have in mind here? > There is still some work to be >done, but as there appears to be a need, I will commit the preliminary code >this week. > Coolness :-) > > As a side note, when the code is available, the notification names will be >available in IWMNotifications.[hm]. > Got it, I'll check it out as soon as it is commited. Laters, Chad > >- Ian > >-----Original Message----- >From: Chad Hardin [mailto:ceh...@ma...] >Sent: Wednesday, June 04, 2003 5:30 PM >Cc: int...@li...; >sim...@so... >Subject: [Interfacewm-discuss] Re: [Simplygnustep-discuss] GSDock and >interfacewm interaction > > >#3 should say the "Title" of the window, not the "Tile" hehe >Chad > >Chad Hardin wrote: > > > >>As you may know I am making a Dock.app for gnustep. >> >>It's a bit of a hybrid between the next stle and the OS X style of dock. >> >>How is it like next? It has tiles and is on the right edge of the >>screen. >>How is it like OS X? It is centered on the right edge and grows as >>things are added to it. It also shrinks to take in more icons. The >>plan is also to automatically "swallow" all App Tiles. I would alos >>like to put miniwindows in it as well >> >>Anyhow, I'm gonna need some interaction with interfacewm. For >>example, I'm gonna need to be able to know when windows are to be >>minimized as well as other information. >> >>I would like to keep all X11 specific stuff out of GSDock.app. Soo... >>I would need interfacewm to tell me, (via >>NSDistributedNotificationCenter?) that a window is to minimized along >>with: >> >>1. An NSImage of the windows contents, preferebly smoothly scaled to >>no larger than 64x64. >>2. A non X11 way of identifying the window. >>3. The tile of the window >>4. The pid of the application which owns the window (maybe not necc) >>5. Probably a few more things. >> >>Anyhow, this would make interfacewm a bit easier to develop since all >>it would have to do is hide the window and pump out a notification. >>Likewise, when a window is to be unminimized, i would just tell >>interfacewm to display it. >> >>Are you guys interested in working together on this? >> >>Thanks! >> >>Chad >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Etnus, makers of TotalView, The best >>thread debugger on the planet. Designed with thread debugging features >>you've never dreamed of, try TotalView 6 free at www.etnus.com. >>_______________________________________________ >>Simplygnustep-discuss mailing list >>Sim...@li... >>https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss >> >> > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The best >thread debugger on the planet. Designed with thread debugging features >you've never dreamed of, try TotalView 6 free at www.etnus.com. >_______________________________________________ >Interfacewm-discuss mailing list >Int...@li... >https://lists.sourceforge.net/lists/listinfo/interfacewm-discuss > > |