Re: Disabling_Expose_for_some_windows,_some_day?
-
I'm not joking, I'm illustrating an interesting case.
Let's say you have a window whose level is above the Desktop background
level and below the desktop icons level (which is possible AFAIK).
Should this window be exposed to Expose?
P.S: I reformatted the title since French rich typography is not
supported by the mailing list.
On Monday, January 26, 2004, at 05:38 PM, Glen Simmons wrote:
> I'm not sure if you're joking, but I'll bite. Since it's a special_______________________________________________
> type of window, I'd say it's a special case, like the dock, the menu
> bar, menus, etc. And I don't think this is a case of one application
> (the Finder) overriding system behavior, rather a system behavior
> centered around one (special) window.
>
> On Jan 26, 2004, at 10:02 AM, Stephane Sudre wrote:
>
>> On Monday, January 26, 2004, at 04:25 PM, Glen Simmons wrote:
>>
>>> [...]It shouldn't be affected by an application.
>>
>> Like the Finder for instance?
>>
>> Because IIRC, the Desktop is a window.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
> Or, if Apple really feels like inhibiting abuse, they could make it
> an option that has to be explicitly turned on for each application,
> just like Accessibility is. They could even bring up a dialog saying:
> "This app wants to cripple your use of Expose. Do you really want
> that?".
I do not agree with this, an application can choose to not quit when
login out, an application can set itself as open when login in, an
application can decide to not show its icon in the Dock, and I'm sure
there are other behaviors Apple lets the developpers handling their own
way.
I think a simple flag on the window is acceptable.
As developers, we see that when a user is not comfortable with a
behavior, we get a lot of mail requesting a change. Why would we
continue making things users disagree with ?
At least, if this is not Apple's point of view, windows having
kCGDesktopWindowLevel should not be concerned by Exposi. But again,
GeekTool can also make windows transparent and NSStatusWindowLevel
(which is on top of everything) and perhaps users wants them to be
untouched, here the problem is more complex, because some users would
like them to go away with exposi, but this has to be coded by the
developer, not imposed by Apple.
Best regards
--
Yann Bizeul - yann at tynsoe.org
http://projects.tynsoe.org/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
op 26-01-2004 20:47 schreef Stephane Sudre
> Let's say you have a window whose level is above the Desktop background
> level and below the desktop icons level (which is possible AFAIK).
> Should this window be exposed to Expose?
I have an application like that. It displays a window covering the entire
desktop at kCGDesktopWindowLevel (click through). I'm using LSUIElement = 1,
so there is no dock icon. At present Expose works as follows:
F11: my background window slides to the top of the window.
F9/f10: my background window is _not_ displayed.
Since my application is essentially replacing the desktop picture (wich is
exempt from Expose) I would like to be able to opt out of Expose too.
> P.S: I reformatted the title since French rich typography is not
> supported by the mailing list.
Yes, why can't we use a simple accent anno 2004?
Patrick
--
Hieper Software
w: www.hieper.nl
e: <info...>
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I too have an application which has a window that can sit on the
desktop under the desktop icons and have had user requests about
Expose, e.g. from MacUpdate: "The Calendar-On-Desktop feature is one of
the best ideas I've seen since Expose. The one only problem is it
doesn't work with Expose. :("
My take on this is that I think it just didn't occur to the Expose
developers that there would be valid reasons for not moving windows
aside.
I agree that there are issues with every developer thinking their
application special and wanting their applications' windows omitted
from consideration. On the other hand, we have seen in this discussion
that several applications could be validly omitted.
With Stephane, I think that windows below desktop icon level should be
automatically omitted from Expose. There may also be a case to argue
that some windows sitting just above the icons may be a part of the
desktop as well. The logic is these windows _are_ part of the desktop,
so shouldn't be removed when using Expose's reveal desktop feature.
Anyway, as I intimated, Expose is a 1.0 product and later versions may
well fix this issue.
Karl
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Quoting Karl Goiser <kg...>:
> With Stephane, I think that windows below desktop icon level should be
> automatically omitted from Expose.
<soapbox>
Log a bug!
Log a bug!
Log a bug!
</soapbox>
I agree that there should be some (non-screwy) way to deal with Expose (or for
Expose to deal with others).
I think the best way we can all get something like this to happen is to act
uniformly. AFAIK, there is no formal "feature-petition" process so our best (and
only?) mechanism is for everybody who agrees to let Apple know via the most
available channel, http://radar.apple.com/ .
-daniel
--
Do your kids need more space?
Get Low-cost Loft Bed Plans!
http://loft.hedrick.org/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
At 16:07 Uhr -0500 29.01.2004, Daniel Hedrick wrote:
> AFAIK, there is no formal "feature-petition" process so our best (and
> only?) mechanism is for everybody who agrees to let Apple know via the most
> available channel, http://radar.apple.com/ .
Actually, that *is* the formal feature-petition mechanism. Just
select "New Feature" as the kind of problem.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Jan 29, 2004, at 3:44 PM, Karl Goiser wrote:
> I agree that there are issues with every developer thinking their
> application special and wanting their applications' windows omitted
> from consideration. On the other hand, we have seen in this
> discussion that several applications could be validly omitted.
This is a common paradigm in APIs that I just don't understand. If
people keep their windows from going away when they ought to, the
result is a poor program that people don't want to use. Apple (or
anyone else) needn't keep us from something just becuase 90% of the
time it's inappropriate. We can figure out what's in the 10%. If the
developer fails, the user will figure it out.
(I'm not blaming Apple on this one: this is probably more of an
unimplemented feature than an executive decision of censorship. I mean
this all more generally. Consider the soapbox firmly under my feet.)
A good language/API ought not protect developers from bad programming
practices, since many are good in a few cases. A good language/API
ought only not to encourage such practices by its nature.
*cough*visualbasic*cough*
Peter
*cough*
-- ---<>--- --
A house without walls cannot fall.
Help build the world's largest encyclopedia at Wikipedia.org
-- ---<>--- --
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Thing is, with my application, everybody said that it needs to work
with Exposi etc etc. Then I started thinking about the issues and came
up with an alternate solution. In the end, the result seems much
better than if Apple had provided a way of disabling Exposi.
So I think that if people think more about their apps and their apps'
requirements, they may discover something themselves!
Karl
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Many, many thanks to Richard Wareham, developer of the *great* desktop
manager (If you don't know, give it a try, really amazing. Thats an
utility to give MacOS X Virtual Desktop feature "a la" Un*x :
http://wsmanager.sourceforge.net/). Since this one is opensource and I
noted that while running, my window were kept in place during exposi, I
asked him the way to do this and it gave me a nice solution.
Here is what I took from the source code, rearranged to fit into a
WindowController subclass :
-(void)setSticky:(BOOL)flag {
CGSConnection cid;
CGSWindow wid;
wid = [[ self window ] windowNumber ];
cid = _CGSDefaultConnection();
int tags[2];
tags[0] = tags[1] = 0;
OSStatus retVal = CGSGetWindowTags(cid, wid, tags, 32);
if(!retVal) {
if (flag)
tags[0] = tags[0] | 0x00000800;
else
tags[0] = tags[0] & 0x00000800;
retVal = CGSSetWindowTags(cid, wid, tags, 32);
}
}
Thanks to him again.
Le 31 janv. 04, ` 01:19, Karl Goiser a icrit :
> Thing is, with my application, everybody said that it needs to work--
> with Exposi etc etc. Then I started thinking about the issues and
> came up with an alternate solution. In the end, the result seems much
> better than if Apple had provided a way of disabling Exposi.
>
> So I think that if people think more about their apps and their apps'
> requirements, they may discover something themselves!
>
>
> Karl
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
>
Yann Bizeul - yann at tynsoe.org
http://projects.tynsoe.org/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Am 02.02.2004 um 20:08 schrieb Yann Bizeul:
> Here is what I took from the source code, rearranged to fit into a
> WindowController subclass :
Great!
I suppose we can expect a new version of GeekTool very soon then? :)
Also, what are you going to call the preference setting?
"Ignore Expose"?
I ask because I might add the same option to one of my apps and I think
it would be best if we had some kind of a UI standard here.
bye. Andreas.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Hi,
In fact I won't provide a setting for now. Desktop level window are
ignored, "always on top" windows are exposed. Seem logic to me.
Do you think I should add a preference for this ?
Since Apple did respect some rules regarding expose, I think we should
act the same. Expose must keep transparent to the user and I don't
think we should confuse people with this.
Regards,
Le 2 fivr. 04, ` 20:46, Andreas Mayer a icrit :
> Am 02.02.2004 um 20:08 schrieb Yann Bizeul:--
>
>> Here is what I took from the source code, rearranged to fit into a
>> WindowController subclass :
>
> Great!
>
> I suppose we can expect a new version of GeekTool very soon then? :)
>
> Also, what are you going to call the preference setting?
>
> "Ignore Expose"?
>
> I ask because I might add the same option to one of my apps and I
> think it would be best if we had some kind of a UI standard here.
>
>
> bye. Andreas.
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
>
Yann Bizeul - yann at tynsoe.org
http://projects.tynsoe.org/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 2 fivr. 04, at 20:08, Yann Bizeul wrote:
> Many, many thanks to Richard Wareham, developer of the *great* desktop
> manager (If you don't know, give it a try, really amazing.
Indeed it's a nice piece of work.
> Thats an
> utility to give MacOS X Virtual Desktop feature "a la" Un*x :
> http://wsmanager.sourceforge.net/). Since this one is opensource and I
> noted that while running, my window were kept in place during exposi, I
> asked him the way to do this and it gave me a nice solution.
> Here is what I took from the source code, rearranged to fit into a
> WindowController subclass :
>
> -(void)setSticky:(BOOL)flag {
> CGSConnection cid;
> CGSWindow wid;
>
> wid = [[ self window ] windowNumber ];
> cid = _CGSDefaultConnection();
> int tags[2];
> tags[0] = tags[1] = 0;
> OSStatus retVal = CGSGetWindowTags(cid, wid, tags, 32);
> if(!retVal) {
> if (flag)
> tags[0] = tags[0] | 0x00000800;
> else
> tags[0] = tags[0] & 0x00000800;
>
> retVal = CGSSetWindowTags(cid, wid, tags, 32);
> }
> }
But any luck, does anybody know how to retrieve the windowNumber of a
Carbon window ?
(I know I'm not on the Carbon-dev list, but it's worth a shot on this
list too).
Thanks
Jerome
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Hi,
All is inside the bit of code ` pasted, the window number is get by :
> wid = [[ self window ] windowNumber ];windowNumber is a method of NSWindow
Best regards,
Le 3 fivr. 04, ` 09:47, Jirome Foucher a icrit :
> On 2 fivr. 04, at 20:08, Yann Bizeul wrote:--
>
>> Many, many thanks to Richard Wareham, developer of the *great* desktop
>> manager (If you don't know, give it a try, really amazing.
>
> Indeed it's a nice piece of work.
>
>> Thats an
>> utility to give MacOS X Virtual Desktop feature "a la" Un*x :
>> http://wsmanager.sourceforge.net/). Since this one is opensource and I
>> noted that while running, my window were kept in place during exposi,
>> I
>> asked him the way to do this and it gave me a nice solution.
>> Here is what I took from the source code, rearranged to fit into a
>> WindowController subclass :
>>
>> -(void)setSticky:(BOOL)flag {
>> CGSConnection cid;
>> CGSWindow wid;
>>
>> wid = [[ self window ] windowNumber ];
>> cid = _CGSDefaultConnection();
>> int tags[2];
>> tags[0] = tags[1] = 0;
>> OSStatus retVal = CGSGetWindowTags(cid, wid, tags, 32);
>> if(!retVal) {
>> if (flag)
>> tags[0] = tags[0] | 0x00000800;
>> else
>> tags[0] = tags[0] & 0x00000800;
>>
>> retVal = CGSSetWindowTags(cid, wid, tags, 32);
>> }
>> }
>
> But any luck, does anybody know how to retrieve the windowNumber of a
> Carbon window ?
> (I know I'm not on the Carbon-dev list, but it's worth a shot on this
> list too).
>
>
> Thanks
> Jerome
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
>
Yann Bizeul - yann at tynsoe.org
http://projects.tynsoe.org/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 3 fivr. 04, at 13:37, Yann Bizeul wrote:
> Hi,
>
> All is inside the bit of code ` pasted, the window number is get by :
>> wid = [[ self window ] windowNumber ];
> windowNumber is a method of NSWindow
Of course, I know.
What I'm asking is if there's an equivalent call in Carbon to get a
windowNumber from a WindowRef (instead of from a NSWindow).
Jirome
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>> But any luck, does anybody know how to retrieve the windowNumber of
>> a Carbon window ?
>> (I know I'm not on the Carbon-dev list, but it's worth a shot on
>> this list too).
Jerome,
well, at worst you could try creating an NSWindow for your Carbon
window using initWithWindowRef: or whatever it's called...
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
