Button issues

WARNING: You currently have Javascript disabled!
This website will not function correctly without Javascript enabled.

benway

343 discussion posts

Hey, great addition! Some things I've notice so far:
The buttons lag behind when you move a window (probably stating the obvious) (see pic)
It would be nice to have a single button for scooting the windows from one monitor to the other. (when you have only two monitors, you don't need a "next" or "previous".
It would be handy to be able to "move up" or "move down" the newly added buttons in list to show in the order you want on the taskbar (see pic)

• Attachment: button Movet.png [5,165 bytes]

button Movet.png

• Attachment: button Scoot.png [17,166 bytes]

button Scoot.png

Jun 24, 2009 • #1

The button lag is a consequence of the way I designed the system. I opted for a "polling" system, instead of hooking each individual window and adversely affecting system performance. This means a slight lag (500ms to 1000ms), but I hope it's something we can all live with.

The "Next Monitor" button does move it between both monitors, or are you asking for something different?

Button ordering is on my to-do list for the next beta.

Thanks!

Jun 24, 2009 • #2

benway

343 discussion posts

Quote:

The "Next Monitor" button does move it between both monitors, or are you asking for something different?

Button ordering is on my to-do list for the next beta.

Thanks!

Jon, I suppose we just need a different icon for when you just have two monitors and you're just using one button to go in both directions. Something like [].
Also, the buttons look like they're a pixel low. :wink:

Great work!

• Attachment: button low.png [2,217 bytes]

button low.png

Jun 24, 2009 • #3

Once the button designs have been completed by the talented Chris Ysebert, then we can critique them.

He has some great ideas in mind, and they should be ready in the next few weeks. The reason it looks 1px too low for you there is that you are using a button that doesn't match your theme. I'll include a button for the Zune theme (which I believe is what you're using there, but correct me if I'm wrong)

Jun 25, 2009 • #4

benway

343 discussion posts

Quote:

Once the button designs have been completed by the talented Chris Ysebert, then we can critique them.

Yep, Zune. :-)

(see, seems to be a very popular theme...)

Jun 25, 2009 • #5

benway

343 discussion posts

Buttons overlapping on Google Chrome using XP... (see pic)

Tough one, since Chrome has the Vista/W7 spacing even on XP.

• Attachment: googly.png [7,536 bytes]

googly.png

Jun 26, 2009 • #6

Apollo29

23 discussion posts

Skype 4.1 Beta also has an overlap problem with the button on Windows 7.

• Attachment: Skype 4.1 beta.png [4,746 bytes]

Skype 4.1 beta.png

Jun 28, 2009 • #7

benway

343 discussion posts

Quote:

Skype 4.1 Beta also has an overlap problem with the button on Windows 7.

Let's blame Skype and Chrome. :-P

I wonder how Skype would position it's button if the DF button was there first?

Jun 29, 2009 • #8

Apollo29

23 discussion posts

More than likely the same way it did in the screen cap :-D

Jun 29, 2009 • #9

benway

343 discussion posts

MS Office communicator = not standard title bar style or size:

• Attachment: communicator.png [2,795 bytes]

communicator.png

Jun 29, 2009 • #10

Atroos

13 discussion posts

Quote:

Any chance of an option in the near future to choose the hit on system performance if a user wants, so it doesn't lag behind?

Jul 2, 2009 • #11

benway

343 discussion posts

Quote:

Hmm, it seems I'm seeing something quite a bit longer than 500ms to 1000ms delay. I can quick grab a window and scoot in to the other monitor and still see the DF buttons stay behind on the other monitor. Seems nearly a second...

Jul 2, 2009 • #12

Kevin F.

450 discussion posts

1000ms is a second . as long as they don't float for 2 seconds its nothing to really report.

Jul 3, 2009 • #13

benway

343 discussion posts

Quote:

1000ms is a second . as long as they don't float for 2 seconds its nothing to really report.

Haha, good one. milliseconds does sound like so much less than a second. :-P

Guess I should have googled up a conversion table.

But, I'm afraid this noticeable lag is going to be pointed out as a flaw by reviewers, because it does seem like something's wrong (thus my reporting it). I'd consider going the other route of sticking them solid if the performance is negligible. I'm not criticizing this great product (Jon knows I've been here since early on supporting it), but trying to help make it better.

Jul 4, 2009 • #14

Kevin F.

450 discussion posts

Right with ya benway, I'm one of the longhauls too remember? Lol.

I just figured Jon had his ideas for them that would reduce that lag, but for now its to be expected.

Anyone know how fast ultramons buttons move? We can do better than them in everyway!

Jul 5, 2009 • #15

Thanks for the encouragement everyone.

I will be working to reduce the lag, but I want to avoid polling more frequently (performance) or hooking individual windows (performance/stability). I'll keep everyone posted if I come up with a good method.

Jul 5, 2009 • #16

Kevin F.

450 discussion posts

has anyone played with ultramon? How fast does it update? Jon should be able to match them within reason.....

Jul 6, 2009 • #17

Apollo29

23 discussion posts

I would like to note that in the latest beta that Skype is worse than before. The custom button from display fusion covers the close button within Skype. Please review attached picture. I would also like to note that DF doesn't even try to draw its custom buttons on Office Communicator in this latest build? Nice job with the new buttons by the way. They look very good.

• Attachment: Skype.png [5,134 bytes]

Skype.png

Jul 6, 2009 • #18

benway

343 discussion posts

Quote:

Office seems to be it's own beast... :-(

• Attachment: office_DF.png [7,440 bytes]

office_DF.png

Jul 6, 2009 • #19

benway

343 discussion posts

Quote:

Thanks for the encouragement everyone.

Jon, if you stay with the current implementation, I might suggest turning the buttons off during a drag and then back on when the window is stopped (if that's possible for the current window only). This would hide the perceived lag problem. (just a thought)

Jul 6, 2009 • #20

sfwrtr

273 discussion posts

Quote:

[size=1](XP SP2 3.62GHz 4GB RAM v3.0.102 updated)[/size]

I'd like to vote for a performance option, here. The caption icons are much too lazy when redrawing. Distracting, in fact. I'm guessing they are a floating topmost level window. When something happens quickly, you get a momentarily overlay. For example, I use the auto-hide feature of the task bar (yours and Windows). See the picture. Moving a window quickly causes the icon to chase the caption, like the Windows mouse-tails feature.

I like the feature, but wouldn't use it the way it behaves now.

Last, do you really want to use the generic term titlebar? Under Windows, this part of the window is usually referred to as the caption.

• Attachment: lazyicon.JPG [32,571 bytes]

lazyicon.JPG

Jul 7, 2009 • #21

PeterDackers

44 discussion posts

Although you are right about the term caption, I think titlebar speaks more to itself. Especially to people who's native language is not English? Just a thought.

And I wouldn't call the redrawing distracting to be honest, yes it's noticeable, but that's it. Maybe a good idea would be like 'benway' suggested? Turning them off while dragging. On the other hand you could go completely bananas and let the user type in a polling rate, but I'm afraid a lot of people will then change it to '0' and start complaining.

Sorry I can't add anymore than that Jon, the latest Beta seems to be running fine over here after I've excluded some applications from the titlebar buttons. For example: ZBrush.

Jul 7, 2009 • #22

sfwrtr

273 discussion posts

Maybe I ought to clarify what I consider distracting: Something that moves asynchronously to what is being moved, that is, two different movements when you expect only one. Whilst turning off the caption button when dragging a window would work, it doesn't fix the problem when the task bar drops down over the window caption and the button (appears to) slide on top of the task bar.

That said, and as Windows programmer to Windows programmer... it just looks amateurish. I would rather not enumerate the number of times I've been told to fix a behavior that I thought wasn't that bad. :cry:

(Of course, a few of them were genuine Windows behaviors, but that was a different battle.)

Jul 7, 2009 • #23

I completely understand, and I always hate things that seem half-baked. I am very happy to report that the button lag is completely gone in the upcoming Beta 3. I spent ~15 hours last weekend re-writing the entire hooking system to support this new feature. I am now using global hooks to update the titlebar buttons in realtime, with 0 lag. Because the hooking has proved so fast I was also able to reduce the poll frequency from 500ms to 1250ms, which has actually resulted in a performance increase despite the hooks.

Good news all around. The only time that the hooks don't work is a 32bit application running under a 64bit version of Windows. This is something I just can't work around, unfortunately. DisplayFusion is running as a 64bit process (on 64bit Windows) and can't load a 32bit hook DLL. I am trying to resolve this issue, but it will take some real voodoo magic.

Jul 8, 2009 • #24

benway

343 discussion posts

Bravo on the titlebar buttons. Virtually no lag now (except when you click for a window to jump to the next monitor the buttons are left behind for a split second - but livable :-)

) They still float around slightly when you wiggle a window, but no one is really going to notice the movement now. Great job! Keep doing that VooDoo that You Do... 8-)

Jul 9, 2009 • #25

Indeed, much of it is voodoo magic... especially in x64 versions of Windows.

When you say they hang around for a split second, are we talking about 50ms, 500ms or 1 second?

Jul 9, 2009 • #26

Kevin F.

450 discussion posts

I don't see any lag for jumping...

Something a little unrelated though: Holding the move to next monitor shortkey still queues infinity, aka holding it resulting in a moving window for a while.

Jul 9, 2009 • #27

@pyrobob: There isn't much I can do about that. If someone wants to move the window that many times than more power to them.

Jul 10, 2009 • #28

Kevin F.

450 discussion posts

Eh? No way to make DF not listen after its held for a second?

Jul 10, 2009 • #29

benway

343 discussion posts

Quote:

Indeed, much of it is voodoo magic... especially in x64 versions of Windows.

When you say they hang around for a split second, are we talking about 50ms, 500ms or 1 second?

Oh, barely noticeable. Maybe 100ms.

Jul 10, 2009 • #30

PeterDackers

44 discussion posts

I thought I'd open a reply here, didn't want to open a completely new topic regarding some issues with the buttons. After all, this topic is called 'Button issues'.

First of all, the lag of the buttons is gone, the buttons look great with the new mouse hover and I totally love them. Better yet, how could I've ever done without them? Very nice job Jon!

I did however found some strange behavior while dragging the Task Manager under Vista. (It also happened in Beta 03, but then I saw you released Beta 04, so I gave that a spin first). When I open the Task Manager in Vista, all is fine. But as soon as I click the Caption bar or drag the window slightly, the buttons seems to disappear under the window and loose their functionality. (Shown in the attached screen shot). It's highly repeatable as it happens every time I open the Task Manager. Anything you want me to check on this end? Let me know.

Windows Vista Home P. OEM. 32-bit.

^{/Edit: added my edition of Windows.}

• Attachment: task_manager.png [28,827 bytes]

task_manager.png

Jul 10, 2009 • #31

@pyrobob: I decided not to rate-limit the HotKeys, in case someone comes up with a use for wanting a repeating one. If you don't want it to repeat, don't hold the keys down.

@PeterDackers: Sorry, that is a known issue.

It isn't specific to Task Manager, it will happen with any window that is "always on top". I'm trying to have it worked out for Beta 5. Thanks!

Jul 10, 2009 • #32

grisham

2 discussion posts

Quote:

Jon, I suppose we just need a different icon for when you just have two monitors and you're just using one button to go in both directions. Something like [].

I second that!
Looking forward to the final button designs.

Jul 15, 2009 • #33

Just waiting for 1 more button, should make it into Beta 8.

Jul 19, 2009 • #34

Was this helpful?

(-)

<< Discussions

Title

Confirm

Confirm

Confirm

Button issues