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.
previous month january 2004 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today