Winstep

Software Technologies


 Winstep Forums


Print view
Board index : Winstep Forums : General Discussion  [ 235 posts ] Go to page Previous  1 ... 12, 13, 14, 15, 16  Next
Author Message
 Post subject: Re: So, what's next after v18.3?
PostPosted: Mon May 28, 2018 8:39 pm 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
winstep wrote:
Ah! Well, that rapid glow effect, as used right now, lets you know when what you are about to drop is going to change the icon image.

With the changes, it will let you know instead that what you are about to drop (normally a document) will be opened by the application the icon under the pointer belongs to (OR that you are about to change the icon image).

In other words, you won't have an effect *dedicated* just to letting you know that you are about to customize an icon's image via drag & drop.


Ok, so here is what I did:

The icon will now also glow to let you know you are dropping a document to be launched by an application. However, I still wanted to make a distinction between opening a document and customizing the icon, so the icon will flash rapidly when dropping a document and more slowly when customizing an icon.

For instance, Vlad, if you are dragging a PNG file over an image processing application icon, if you press the ALT key (which, in your particular case, means you want to customize the icon) the icon will start slow flashing. Release the ALT key, however, and the icon will start flashing rapidly (which means the image application will launch and open that PNG file instead).

Makes sense?

I also try to make some basic pre-filtering: for instance, if you try to drop a .TXT file into an Internal Command icon (which is meaningless and will only result in the TXT file being added to the dock anyway), the icon will not flash AT ALL.

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Mon May 28, 2018 8:39 pm 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
seeker wrote:
you are the best :)


Yes. Yes I am. :lol: :wink:

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Tue May 29, 2018 4:40 am 
Offline

Joined: Thu Oct 05, 2017 1:28 pm
Posts: 104
winstep wrote:

Quote:
For instance, Vlad, if you are dragging a PNG file over an image processing application icon, if you press the ALT key (which, in your particular case, means you want to customize the icon) the icon will start slow flashing. Release the ALT key, however, and the icon will start flashing rapidly (which means the image application will launch and open that PNG file instead).

Makes sense?

I also try to make some basic pre-filtering: for instance, if you try to drop a .TXT file into an Internal Command icon (which is meaningless and will only result in the TXT file being added to the dock anyway), the icon will not flash AT ALL.



Yes, makes sense.
P.S. I am not going to say you are the best, like in previous posts :D , instead I will say your product is the best. I do not regret the decision to buy and I will gladly do whatever I can to support it.


Back to top
 Profile  
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Tue May 29, 2018 4:14 pm 
Offline

Joined: Sat Apr 07, 2018 7:19 pm
Posts: 346
Location: UK
Not any kind of problem as such, but when you have the clock module set to open the WS calendar mod, and you click the clock, while already having the calendar module running, another calendar pops up at the mouse pointer, instead of just bringing the already present cal mod to the front. I would have thought that would be the logical thing, but then.... :)

Oh, I've just had a thought re: the problem with text in the mail, moon phase and battery mods being too small on startup - could it be that I may have set a font size that is ill-fitting or something? (However, in the past the mail mod always displayed the text correctly from start up.) I'll try resetting the font sizes anyway. when I get a chance.

Busy again right now with the blessed NET mod, but just keep getting grossly enlarged in-shelf versions of in and out.

_________________
nexter - so, what's next?


Back to top
 Profile  
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Tue May 29, 2018 4:23 pm 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
Vlad wrote:
P.S. I am not going to say you are the best, like in previous posts :D


LOL! Darn! :)

Vlad wrote:
instead I will say your product is the best. I do not regret the decision to buy and I will gladly do whatever I can to support it.


Thanks, Vlad. :)

nexter wrote:
Not any kind of problem as such, but when you have the clock module set to open the WS calendar mod, and you click the clock, while already having the calendar module running, another calendar pops up at the mouse pointer, instead of just bringing the already present cal mod to the front. I would have thought that would be the logical thing, but then.... :)


Not really, if you think about it. No need to disturb the normal desktop calendar module, you just use a pop-up clone.

Imagine a world where you can have as many versions of desktop modules as you want (that world clock thingy, weather for different locations, etc...). Now WHICH of those calendar desktop modules are you going to use as a pop up? lol

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Tue May 29, 2018 4:41 pm 
Offline

Joined: Sat Apr 07, 2018 7:19 pm
Posts: 346
Location: UK
winstep wrote:
Vlad wrote:
P.S. I am not going to say you are the best, like in previous posts :D

LOL! Darn! :)

Aww, what a shame eh? ;)
winstep wrote:
Vlad wrote:
instead I will say your product is the best.....

Thanks, Vlad. :)

And so say all of us! It's one of a kind. It's already the best desktop GUI replacement ever, and it shows how the desktop/workspace environment of an OS should be - totally flexible and configurable, and with clout!
winstep wrote:
nexter wrote:
Not any kind of problem as such, but when you have the clock module set to open the WS calendar mod, and you click the clock, while already having the calendar module running, another calendar pops up at the mouse pointer, instead of just bringing the already present cal mod to the front. I would have thought that would be the logical thing, but then.... :)


Not really, if you think about it. No need to disturb the normal desktop calendar module, you just use a pop-up clone.

Imagine a world where you can have as many versions of desktop modules as you want (that world clock thingy, weather for different locations, etc...). Now WHICH of those calendar desktop modules are you going to use as a pop up? lol


Yeah, I suppose you're right re: clock etc. And ooh yeah, multi-modules will be amazing! (Have a look at my mock-ups re: a 'warped bar' that'll be up in a day or two for how I envisage one way of using them!) Yep, multiple clocks will be very useful, I could do with at least two different time zones certainly. :)

_________________
nexter - so, what's next?


Back to top
 Profile  
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Tue May 29, 2018 5:59 pm 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
Ric, please don't be upset if I seem not to be responding to certain subjects, I'm just overwhelmed right now and quickly running out of time for the official release. When that happens I'm forced to filter out some stuff until I can deal with it later (drawback of this is that by the time I can some things have already slipped my mind lol).

Can't have v18.5 turning into v18.6, there are only 3 days left in the month for this not to happen, and I still haven't written the news announcement lol.

Anyway, here's something else I just added that I think it's important (at least, something that was also getting on my nerves):

I have a global setting that applies to docks and the Shelf saying 'Hide or collapse automatically only when other windows have the focus'. What this setting does is prevent the dock or Shelf from auto-hiding until you click on another window, but, for some reason unknown to me, users didn't seem to like this. If this setting is enabled, the following does not apply to you.

So, with this setting disabled the Shelf would auto-hide as soon as you moved the mouse pointer away from it (or rather, once this happened and the period specified in the auto-hide delay had elapsed). Most people have a very short auto-hide delay.

So what I found happening here somewhat frequently when browsing the Shelf (i.e.; quickly scanning the Shelf left to right with the mouse pointer) and really getting on my nerves, was the Shelf collapsing because the pointer temporarily (and accidentally) went outside of it (normally below into the taskbar, but sometimes above) for long enough to trigger the auto-hide.

So a docked Shelf now no longer auto-hides if the mouse pointer is below it (i.e.; assuming it is docked to the bottom of the screen). This is something that already happens with docks - if you set a large screen offset and then activate a top docked dock, you will notice it does not auto-hide while the mouse pointer is over the empty space between it and the top edge of the screen). This means you can now move the mouse pointer to the taskbar below the Shelf and the Shelf will still remain open.

I also added a small 16 pixel 'invisible buffer space' above the Shelf where auto-hide is not triggered either.

Letting you guys know this in case someone can come up with a drawback for this change.

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Tue May 29, 2018 8:26 pm 
Offline

Joined: Sat Apr 07, 2018 7:19 pm
Posts: 346
Location: UK
winstep wrote:
Ric, please don't be upset if I seem not to be responding to certain subjects, I'm just overwhelmed right now and quickly running out of time for the official release. When that happens I'm forced to filter out some stuff until I can deal with it later (drawback of this is that by the time I can some things have already slipped my mind lol).

Eheh Jorge, no problem, no need to spend time explaining, I know exactly what it's like for you and also know you for the decent bloke that you are. :)
winstep wrote:
Can't have v18.5 turning into v18.6, there are only 3 days left in the month for this not to happen, and I still haven't written the news announcement lol.

No indeed, can't let that happen. Deadlines are deadlines and if not met could turn into dead lines - I know this only too well from my own career.
winstep wrote:
Anyway, here's something else I just added that I think it's important (at least, something that was also getting on my nerves):

I have a global setting that applies to docks and the Shelf saying 'Hide or collapse automatically only when other windows have the focus'. What this setting does is prevent the dock or Shelf from auto-hiding until you click on another window, but, for some reason unknown to me, users didn't seem to like this. If this setting is enabled, the following does not apply to you.

So, with this setting disabled the Shelf would auto-hide as soon as you moved the mouse pointer away from it (or rather, once this happened and the period specified in the auto-hide delay had elapsed). Most people have a very short auto-hide delay.

So what I found happening here somewhat frequently when browsing the Shelf (i.e.; quickly scanning the Shelf left to right with the mouse pointer) and really getting on my nerves, was the Shelf collapsing because the pointer temporarily (and accidentally) went outside of it (normally below into the taskbar, but sometimes above) for long enough to trigger the auto-hide.

So a docked Shelf now no longer auto-hides if the mouse pointer is below it (i.e.; assuming it is docked to the bottom of the screen). This is something that already happens with docks - if you set a large screen offset and then activate a top docked dock, you will notice it does not auto-hide while the mouse pointer is over the empty space between it and the top edge of the screen). This means you can now move the mouse pointer to the taskbar below the Shelf and the Shelf will still remain open.

I also added a small 16 pixel 'invisible buffer space' above the Shelf where auto-hide is not triggered either.

Letting you guys know this in case someone can come up with a drawback for this change.


Sounds eminently sensible to me, although in (what passes for) normal or ordinary use, I don't auto hide, only things that are docked are two docks and the tasklist (don't use a taskbar - no need for it) - although the tasklist will be moved about if you accidentally left-button on it and move - the shelf is set up some pixels above the tasklist, and the latter is the only thing that's always on top. This suits my way of working, esp. as I almost never use maximised windows, esp. not when only using the laptop's horrible 16x9 ratio screen.

But, like everything else, I will try all this when it becomes available of course.

_________________
nexter - so, what's next?


Back to top
 Profile  
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Tue May 29, 2018 10:24 pm 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
Seeker, I think you are going to like this one: you can now set the dock's name directly from the Dock & Shelves tab.

I turned the static label with the dock name into a camouflaged text box - you wouldn't know there was a change just by looking at it, but you can now actually edit the dock's name there.

I've got to stop adding last minute stuff and get on with the release. Jesus! :)

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Wed May 30, 2018 12:36 am 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
Small but useful change: WsMMPlay.exe is now launched asynchronously.

If you ever noticed the Launch animation of the Multimedia Player icon freezing for a moment right after clicking on the icon, that was the reason. Won't happen anymore.

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Wed May 30, 2018 5:13 pm 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
And luckily just found (and fixed) this brand new bug: clicking the weather module icon on the Shelf would keep opening new weather forecast sub-docks.

Only goes to show how changing a little thing can have a profound effect elsewhere on the code. :)

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Wed May 30, 2018 8:10 pm 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
seeker wrote:
if the dock is enabled you cannot access dock properties trough context menu, you can only acces icon/item properties

seeker wrote:
when launching with keyboard shortcut while running a fullscreen app dock attached to QL appears in different position


Ok, you can now Enable/Disable a dock from the right click context menu (Nexus -> Dock and Shelf Management -> Enable/Disable Dock)

This means that when the dock is disabled and you access it from NextSTART you now also have access to the main dock context menu (minus the menu entries related to the screen position of the dock, of course).

Furthermore, I now save the position and orientation the dock had before it was disabled, and restore those when the dock is re-enabled. In practice, if you re-enable a dock being shown by NextSTART, you will actually see it move to its original position and orientation.

Of course, in your case you won't see this happen unless you re-enable the dock, set it to a different position and/or orientation, disable the dock, open if from NextSTART, enable it from there.

As for launching a QL hotspot via keyboard, unfortunately the same thing will still happen: the dock will open wherever the mouse pointer is. Which is actually not a bad thing if you think of it. :)

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Wed May 30, 2018 8:59 pm 
Offline

Joined: Tue Mar 01, 2016 11:46 am
Posts: 321
not sure if this is a bug or a feature, when extending the shelf trough mini tab function it stays open (ie doesnt collapse) even when another window gets focus


Back to top
 Profile  
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Wed May 30, 2018 9:25 pm 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
seeker wrote:
not sure if this is a bug or a feature, when extending the shelf trough mini tab function it stays open (ie doesnt collapse) even when another window gets focus


That's by design. :)

When you expand a shelf by clicking on the right mini-tab, it stays open and does not auto-hide. If you want it to auto-hide normally, either click on a tab to expand it or bump the associated screen edge.

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: So, what's next after v18.3?
PostPosted: Fri Jun 01, 2018 1:33 am 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 9263
Ok, guys, have you noticed, I kind of missed my deadline (at least in the GMT timezone).

Found a last minute issue in Windows 10 that was driving me up a wall to figure out why it was happening so I could fix it. Indeed it should drive me up a wall, because in the end it turned out it was nothing with my code, but with what Windows 10 was doing (these type of issues are REALLY HARD to diagnose, because you are looking and looking for a problem in your code and that is not where the problem lies).

The story of how I figured out what was happening is a bit complex, so please bear with me as I try to explain in plain terms:

Winstep applications are single threaded. This means that when a piece of code is running, it can do so knowing that the routine will run from start to end without some piece of code elsewhere in the same application running at the same time.

The disadvantage of this is that single threaded applications cannot do two or more things at the same time (for instance, rendering icons *and* responding to mouse events). To get around this we deliberately place 'interrupts' at specific points in the code which give other parts of the application a chance to run as well. It's a bit like this: do a little bit of task A, interrupt so task B can also happen, go back to doing another little bit of task A, and so on.

This way the application appears to be always responsive even if it is busy doing something, and, because we know *exactly* where the interrupts will happen (because we put them there), we can test at that point to see if task B did something that would have an influence on task A.

Now, applications can also be multi-threaded. Multi-threaded applications are a REAL nightmare to code properly, because tasks A, B and C are all running at the same time independent of each other. Task A can thus be interrupted by the OS at ANY time to do task B or task C, and if the application hasn't been coded properly via complicated methods such as semaphores and thread synchronization objects to take this into account crashes and weird things will start happening.

Anyway, going back to the story:

Sometime ago I had to work around the fact that Windows itself (not my code) was triggering an unexpected interrupt when rendering thumbnails. Figuring this out was already a nightmare, because that was NOT supposed to happen at that particular point of the code. Once I figured out what and, more importantly, where it was happening, I could work around it, just as if I had placed an interrupt instruction there myself.

So, basically what happens is this: when you open a new tab for the first time, all the icons in it have to be retrieved. Since doing it for the first time normally implies retrieving those icon images from disk, it can take a very long time (in terms of computing time, of course, not human time).

If the Shelf tried to retrieve all the icons before showing the new tab, this is what would happen: you would click on a new tab and absolutely nothing would apparently happen for one second or more while the Shelf was busy retrieving all those icon images - to you, it would look as if the click had not even registered.

So, to keep the Shelf responsive at all times in a single threaded environment, a lot of tricks are employed. As soon as you click on a new tab, the Shelf begins retrieving the icons for the visible row of icons in that tab. If it manages to get all of them in under half a second, great, if not, it stops fetching further icons and shows you the new tab with the icons it already got, and generic app icons for the rest.

This ensures that when you click on a new tab you will get a response in half a second AT THE MOST.

If the Shelf didn't have time to retrieve all the icons in that half second, it will then start fetching and displaying the remainder icons one by one: fetch a new icon, display it, go back to responding to user input, fetch another icon, display it, go back to responding to user input, and so on... I call this 'lazy rendering'.

Now, all these icons are then cached in memory - the next time you open that particular tab, instead of being retrieved from disk the icons will now be retrieved from memory, which is several orders of magnitude faster - this is why a tab with a lot of items in it opens so much faster the second time you click on it.

Even when it has already displayed the visible row of icons, the Shelf will, unbeknownst to you, still be busy in the background fetching the icons for the next row of icons, the one you will see if you scroll down (fetch one icon, cache it in memory, go back to responding to user input, fetch another icon, etc...). When you finally do scroll down, hopefully the Shelf will already have finished retrieving all the icons in that row, so you won't have to see generic placeholder icons again.

Document thumbnails (images, videos, etc...) are also rendered in a similar way. First the Shelf displays all the icons, then it starts rendering those thumbnails one by one, replacing the icons in the Shelf with their thumbnail images as it does so (in the case of thumbnails, using that cool morph effect).

The above was an explanation on how things happen behind the scenes, so you can understand better what I run into now:

I had already noticed, when implementing the UWP Apps tab in the Shelf, that it would sometimes display blank document icons for some Apps instead of the proper icon for that app. Since I had seen this happening in Windows itself (e.g.; also in shortcuts on the Desktop to UWP apps) I figured at the time that this was a bug/issue with Windows itself.

You see, UWP apps don't use real icons like Win32 applications do (i.e.; ICO files). Instead they use PNG images of several sizes stored individually in a repository folder.

Anyway, today, as I was getting some screenshots on a Windows 10 VM for the news of the v18.5 release, something a lot more serious happened: when opening the Apps tab in the Shelf, if I moused over it before it had finished rendering all the UWP app icons (and those take an unusually long time to retrieve) the application would crash with an Access Violation error.

Needless to say, I then spent a very long time looking for a problem in my code, but I couldn't find any or understand why that was happening. Simulating the icon rendering delay on the IDE on a Windows 7 machine did not cause any visible problems, much less a crash.

I finally noticed that instead of the generic app icon, the Shelf was displaying a blank document icon, but only in the icon I had just moused over. The crash did not happen immediately either, the routine that fetches and displays icons that could not have been retrieved in the first half a second was also displaying blank document icons from then on.

This was the crucial clue I needed to figure out what was happening.

You see, as I said above, UWP apps do not have real icons. So, UWP icons are basically a thumbnail of a PNG image, and I had already run into the problem of an unexpected interrupt happening when the application asks Windows to render a thumbnail.

So, this is what was happening: the Shelf would retrieve the first UWP app icon, this would take longer than half a second, so the Shelf displayed that first icon and then proceeded to display generic app icons for the rest. It would then get busy lazy rendering the icons that were still displaying the generic app icon.

In the mean time I would mouse over a UWP icon still displaying the generic app icon, which prompted the Shelf to retrieve the proper icon for that item NOW.

And this is where the problems started - you see, the routine that fetches icons, which is NEVER supposed to be interrupted in the middle of what it is doing, was being interrupted because Windows was rendering a thumbnail for the first lazy rendered UWP icon. Windows should not trigger an interrupt when rendering a thumbnail but for some unknown reason it does - it should NEVER do this, but does. So, this interrupt would allow the Shelf to respond to mouse movements, which would then trigger ANOTHER request for an UWP icon to be rendered while the first was still being processed.

Now, I imagine Windows uses GDI+ to render UWP icons/thumbnails internally, and GDI+ is NOT thread safe. Basically what was happening here was the equivalent of using GDI+ in a multi-threaded environment: because GDI+ is not thread safe, things are going to go very wrong, very soon. Something would get corrupted inside the GDI+ environment, which is what caused the blank document icon to be displayed from then on for every UWP icon, and eventually GDI+ would crash, bringing the application down with it.

Once I figured this out the solution was to treat this as a multi-threaded situation and use a semaphore to make sure the Shelf does not attempt to retrieve another icon while one is still being retrieved.

This should serve as another example on how crashes and strange issues are not necessarily the fault of the application that does the actual crashing.

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
Post new topic Reply to topic Board index : Winstep Forums : General Discussion  [ 235 posts ] Go to page Previous  1 ... 12, 13, 14, 15, 16  Next
Display posts from previous:  Sort by  

Who is online

Users browsing this forum: Google [Bot] and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: