Introduction
I have been so annoyed by applications that have a startup dialog which is Always on Top configured.
By start dialog I mean the annoying box that tells you what program you just opened (and probably opened on purpose so useless information), who the program is registered to (most likely you, more uselessness), and some other random application specific information. Some have loading bars that indicate startup progress, but otherwise they seem basically useless except to show that your program is actually starting (to prevent the user from opening 5 instances during the loading process because they think it's not open yet).
The worst though is when this useless information is displayed over all the useful browsers and documents that I may be working on at the time, making me wait until the application is loaded before I can effectively work on something else again.
Most apps have the sense not to do this, but some still continue the practice.
Now that I'm done ranting...
My Question(s)
My question is..Why?
What is the point of all this?
Why does/did anyone ever do this?
What was the reasoning behind it?
Is anyone else annoyed by this?
Is there any benefit to the end user or developer to use this technique?
Should I ever use a startup dialog like this and when?
Anyone else have other comments/rants/suggestions to share with the community?
I believe you are talking about the 'splash screen.'
Some reasons for it:
It is often thought of as 'branding' in that it reinforces the company's logo.
It can contain some useful info such as version number.
Most importantly, it gives you the impression that the slow starting app is being just a bit more than unresponsive.
I share in your annoyance of Always-on-Top dialogs.
The use of the dialog is to let the user know that the application is actually doing something and hasn't hung. Back in the day, when IO wasn't as fast, it was reasonable to assume that the system is not very responsive while the application is doing its IO, so it was reasonable to bar the user from doing anything else while the application was loading.
Now that IO is faster and more concurrent, there isn't a need for hogging the user's focus and the start-up dialogs should simply be regular dialogs.
Since the main use of the dialog is to indicate application process, I like a visual indication, such as a progress bar. Eclipse does this well IMO.
It's good to have a startup screen so the user gets some feedback that they actually launched the app.
But putting that screen always on top of existing windows, so the user is sure to see it, is a definite no - you should not presume that your application is more important than the user's web browser, email, etc. Unfortunately many developers have a very self-centric view of the world, and think that their application is the most important thing the user is running.
Just gives visual indication that the app is initializing.
Startup dialogs or Splash screens are completely useless for the most part. The only time I think they are any use is if as you suggested a particular program takes a bit of time to load. Some kind of progress indication would be nice.
The only example I can think of is Photoshop. Not strictly necessary but it does take a moment to load.
Related
I need to reduce the volume of a radio that plays in the browser, play a song in my Electron app, then raise the radio volume in the browser again. Is it possible to do it on Electron?
I searched for a library that made isos but I couldn't find anything.
Explained
You could simply do it via the DOM within a renderer process, keep in mind, you wouldn't be able to approach the problem like this if you desire to handle volume within the main process, simply because you cannot access the DOM within the main process.
I mean this may not be the best way, however, it's a simple way, at least in my opinion, and it saves having to include anymore dependencies into the project. Thus in my opinion, possibly making it more stable & reliable, with this approach, you wouldn't have to worry about 'x' dependency changing, expect for Electron itself. I may even go as far to say that it could also mean that it's more performance friendly, as you don't need to load in another dependency, although I'm not confident enough to say that all of this is a solid fact, this is, for the most part, opinion based.
I maintain a gtk3 (though a mixture of gtk2hs and gi-gtk) application that serves as a standalone status bar for tiling window managers called taffybar.
Taffybar has a long standing bug where something happens that causes one of its windows (it can have multiple windows e.g. when displaying on multiple monitors) to stop updating completely (issue here). I have verified through various logging mechanisms that the code that is supposed to be updating the window IS in fact continuing to run. Also, if taffybar is displaying on multiple windows, windows will become affected one at a time -- that is, the hang only seems to affect the window on which it occurs, which rules out anything strange happening on the UI thread or something like that.
Unfortunately, I do not have a consistent way to reproduce the issue. What's worse is that I haven't even been able to come up with a way to detect the issue programmatically. With that said, it is relatively easy to get the issue to occur as it has gotten much worse recently with the new icon loading mechanisms that have been added (it seems to happen about once every 5 minutes in the latest version). This reminds me that another thing I should mention is that I am relatively certain that the issue has something to do with pixbufs and image display because I have never seen the issue occur when the workspace images module is not active.
I hate to ask a question without even being able to provide a consistent way to reproduce the issue, but I'm simply at a loss as to how to go about tackling/debugging this issue. It's hard for me to imagine how the behavior that I have described is even possible, actually. I'm hoping that something about the idiosyncratic nature of the issue might be enough for someone more knowledgable about gtk than I to make some guesses as to what the issue might be.
To make my questions as explicit as possible I'll phrase it as follows:
What could cause a gtk application window to hang (stop updating) without crashing the application or the UI thread, or affecting any of the other windows created by the application?
EDIT: One more interesting quirk of this bug is that even though the window stops updating, it still responds to mouse input.
EDIT2: Another thing worth noting is that occasionally, I have gotten this message:
gtkicontheme.c:3956:proxy_pixbuf_destroy: assertion failed: (icon_info->proxy_pixbuf != NULL)
I have also gotten the following message when I attempt to destroy the hung window in code:
Source ID 363524 was not found when attempting to remove it
I am loading icons from the icon theme sometimes
I believe that the cause of this issue was simply that some UI updates were not being performed on the main UI thread. I can't be 100% certain of this because I was never able to reproduce. See this comment for more details:
https://github.com/taffybar/taffybar/issues/228#issuecomment-402591159
To begin with, I understand that Microsoft offers no way to programatically alter the (modern) start menu - on purpose.
Nevertheless, I'm looking for a way to still do it. I might use it to make a tool to sync the start menu between devices - or to automatically place often used items into thematically sorted groups (office, games, tools). The reason is that I have multiple devices, and really suck at manually managing the start menu - so I just use search or the alphabetic list most of the time.
So, does anybody know how to programatically add, remove, edit tiles? I could imagine solutions including:
Using undocumented APIs (can you still call it an API if it is not documented?)
Directly editing the tile database (e.g. TileDataLayer) - downside is that it seems to be a binary format, which is not known, and you'd have to restart the shell for changes to take effect.
Hooking DLLs or poking around in memory - yikes - but not worse than what other "desktop modding" tools like WindowBlinds would do
Using accessibility APIs, or faking mouse/keyboard input - this would most probably work, but it would be a bit spooky seeing the cursor move around, and it seems even more frail than the others.
I searched a bit, and think there is probably no solution available right now, but you can see this as a challenge to come up with a solution :-)
As you say, there isn't a way to do this.
As an alternative, did you know that you can easily find apps to launch by pressing the windows key and then typing the name of the app you want to launch? This is how I launch anything that isn't pinned to my taskbar. The device I'm on and the order of items in a list or what's pinned where become irrelevant when working this way.
I use xlib. I want to remember window position and restore it to that position the next time it starts. This will help the user as he won't need to move/size the window to the desired position at every start.
It works more or less Ok, except one case. When the window is maximized, I cannot find the way to determine its true (non-maximized) size and position. Perhaps someone knows how to do it?
There isn't as far as I know a standard way to do this. If you read the source to Metacity for example you can see it keeps this unmaximized size in the MetaWindow object but I don't think it gets stored in a property, and I don't see a property for this in the EWMH or ICCCM specs.
It's possible that some specific window managers might store it in a nonstandard property.
When a window is maximized you could get a property change event with the maximization flag (libwnck is an old library to track this sort of thing, maybe there's a newer one I don't know). However I doubt it's defined whether the resizing happens before or after setting the flag. You could perhaps heuristically assume that a resize covering most of the screen within 1 second of setting the maximize flag was a maximize, or some similar hack.
All that said, I suspect the easiest way to get this feature is to implement it as a window manager extension or plugin, which many WMs support in some way.
There is an old spec for this (X session management protocol) unfortunately the spec is ridiculously broken, unclear and essentially impossible to implement. A core issue that was never addressed - and probably needs app cooperation to address - is how to recognize "the same" window across restarts in order to restore its size.
There are only flawed heuristics for that.
(I wrote metacity and worked on a couple session managers long ago so once I could have told you a lot more, but I've forgotten many details.)
I want to code a trading bot for Magic: The Gathering Online. This bot should wait until someone offers to trade, accept, look through the cards available from the other trader (the information is shown on screen), and perform other similar functions. I have several questions:
How can it know that someone is offering a trade?
How can it know that the other trader has some card (the informaion is stored in pictures)?
I just cannot imagine right now how to do it, I have no experience with it, until now I've been coding only console programs for my physics neŃessities.
First, you should note that some online games forbid bots, as they can give certain players unfair advantages. The MTGO Terms of Service do not seem to say anything about this, though they do put restrictions on anything that might negatively impact the service. They have also said that there is a possibility they will add an API in the future, so they don't seem to be against the idea of automation, but are not supporting it at the moment. Tread carefully here, but it looks like it should be OK to write a bot as long as it is not harmful or abusive. This is not legal advice, and it would be a good idea to ask the folks who run MTGO for permission. edit since I wrote this, it has been pointed out that there are lots of bots already, so there should be no problems writing bots.
Assuming that it is not forbidden by the terms of service, but they do not have an API, you will have to find a way to detect what's going on, and control the game automatically. There's a pretty good series of articles on writing poker bots (archived copy), which has some good information on how to inject a DLL into an application, scrape the screen, and control the application. That might provide you with a starting point for doing this sort of thing.
You might also want to look for tools that other people have already written for doing this. It looks like there are several existing MTGO bots, but they all seem a bit sketchy (there have been some reports of them stealing passwords), so be careful there.
Edit
Since this answer still seems to be getting upvotes, I should probably update it with some more useful information. Since writing this, I have found a great UI automation system called Sikuli. It allows you to write programs in Python that automate a GUI. It includes image recognition features which make it very easy to recognize buttons, cards, and other UI elements; you just take a screenshot, crop it down to include just the thing you're interested in, and do fuzzy image matching (so that changing backgrounds and the like doesn't cause the match to fail). It even includes a custom IDE that allows you to embed those screenshots directly in your source code, so you can see exactly what the code is looking for. Here's an example from the documentation (apologies for the code formatting, doing images inline in code is not easy given StackOverflow's restricted subset of HTML):
def resizeApp(app, dx, dy):
switchApp(app)
corner = find(Pattern().targetOffset(3,14))
drop_point = corner.getTarget().offset(dx, dy)
dragDrop(corner, drop_point)
resizeApp("Safari", 50, 50)
This is much easier to get started with than the techniques mentioned in the article linked above, of injecting a DLL into the process you are debugging. Sikuli runs entirely at the UI level, so you never have to modify the program you are automating or worry about changes to the internals breaking your script.
One thing it is a bit poor at is handling text; it has OCR features, but they aren't all that good. If the text is selectable, however, you can select the text, copy it, and then look directly at the clipboard.
If I were to write a bot to automate something without a good API or text-based interface, Sikuli is probably the first tool I would reach for.
This answer is constructed from my comments.
What you are trying to do is hard, any way you try and do it.
Arguably the easiest way to do it is to totally mimic the user. So the application presses buttons, moves the mouse etc. The downside with this is that it is dependant on being able to recognise the screen.
This is easier if you can alter the games files as you can then just skin ( changing the image (texture)) the required cards to a single unique colour.
The major down side is you have to have the game as the top level window or have the game running in a virtual machine. Neither of which is ideal.
Another method is to read the processes memory. You may be able to find a list of memory locations, which would make things simpler, otherwise it involves a lot of hardwork, a debugger to deduce the memory addresses. It also helps (a lot) to be able to understand assembly.
The third method is to intercept the packets, and alter them. This is easier that the method above as it (at least for me) is easier to reverse engine the protocol as you have less information to deal with. It is just a matter of setting up a packet sniffer and preforming a action with one variable different (for example, the card) and comparing the differences.
The thing you need to check are that you are not breaking the EULA. I don't know how the game works, but most of the games I have come across have a EULA that prohibits (i.e. You get banned) doing any of the things I have mentioned.