Odd Question: Deciding what to display in application window

[Tiassa]

Okay, it's an odd question, but: How does a programmer/designer decide what is displayed in an application window?

That is, I figure there is a reason information displays as it does. To wit, and at the heart of why I'm asking this now:

• Let us say you launch an application. Let's use a torrent app for the example. Now, you choose to search for certain terms, and a long list comes up. If you try to scroll through the list as the search engine pours in the results, then the information continues to skitter on down the list, out of view, so that you must scroll the window down.

Now, I understand there is a reason why the data is displayed as it is. But I don't know what that reason is.

Compare:

• Search for certain terms, and a long list comes up. If you try to scroll through the information, then the window holds steady; you can tell the list is getting longer because the indicator in the scrollbar is shrinking, and your results data (e.g., "Results (473)") at the top of the search return continues to grow.

Why the first, and not the second? Is it a specific protocol coders follow? Or does the method depend on each individual application? Are there classes of applications where different protocols apply?

Practically speaking:

• As the search information comes up, you spy the entry you are looking for. Before you can even click on it, it scrolls away and, as you chase it down the list, the incoming results push it farther and farther away.

• Or ... As the search information comes up, you spy the entry you are looking for. You click on it, but before you can double-click, right-click, click another button within the application window, or even, really, be sure you've clicked the right one, your highlighted file is dashing down the list.

I noticed because it turned a ten-second search effort into thirty seconds, and then a minute before the search engine exhausted itself and I could safely scroll through the result without getting lost by a hundred files suddenly appearing here or there, pushing the list up or down accordingly.

It's a little thing, sure. But it's also annoying. And, to the other, it seems a safe presumption that there is a reason why the application window itself is so passive, simply letting the data tumble past.

But I have no idea what that reason is.

Thanks.

[leopold]

it sounds as if the list is being completed alphabetically.
most directory entries, in my opinion, should be appended rather than inserted when found

it's the programmers choice to use either or any type of listing technique.

edit:
this might be corrected by editing the registry or some tweak in the OS.

edit 2:
i misunderstood the point.
maybe you should lay off the coffee for awhile.

[Stryder]

Your asking an obfuscated question about programming where you want an nonobfuscated response from a programmer.... (:/ I don't think that's possible)

writing to a file in programming requires a number of stages:
(**Note: For simplicity I've left out sanatisation checking and checking if things exist already etc)

• Create a construct.
• Initialise the construct/filehander with a files name/location.
• Opening that filehandler.
• Write to that filehandler.
• Close that filehandler.
• Destroy the construct/filehandler.

I use this example because in your post you are referring to a program that both opens a construct for "Reading a database" and a construct for "write results to an Output Buffer in your application".

Programming doesn't of course step through these stages every time you want to get a search return, otherwise it would chew up a lot of resources and likely end up suffering from some bug or other.

So usually what happens is you try to squeeze in all the requests to a database that you require in one hit so you don't have to access it with multiple sessions.

What is likely happening with your application is that a loop is running based upon some search criteria (probably a Preg_Match) and it's checking dictionary definition of database entries (A pre-creating shortcut for finding matching items) or it's accessing each individual entry one by one and attempting to match a string.

While it's doing that in the background, it will be writing to the Output Buffer in your application which again is an opened construct awaiting on being closed "after" it's completed it's task.

That's why your results will just keep populating and shifting your "Focus" on the page, however it doesn't have to be like that, in fact it would suggest and oversight of a programmer if they are just allowing an open-ended stream of results to be compiled in such a way (such as potential zero-day injections)

What a programmer could potentially do is generate a "cache of results" which is returned in fixed bounds with a limit to the number of return items (paging), it would be easily enough applied through classes (not schooling classes, but programming :Classes)

The thing is however such alterations in the case of your hypothetical application are really something that a programmer can do for a future version, however it's dependent on how well they support their software and if they are both skilled enough and not lazy/in a rush and resorting to "quick programming resolutions".

As for "Programming Standards".

Well there is a certain amount of Ettiquette in regards to formatting code (not deletion I actually mean how it's formatted) and there are various "Documentation methods" that get used in large projects, however there are programs written by people in the bedroom/garage set up whereby they don't follow the design/documentation practices (and that's where the troubles start)

[przyk]

Why the first, and not the second? Is it a specific protocol coders follow? Or does the method depend on each individual application? Are there classes of applications where different protocols apply?

It may not be something the developers decided or thought about at all. Applications generally don't handle all the details regarding how to draw windows and widgets (buttons, scroll windows, tick boxes, etc.) and how they behave. Graphical operating systems provide one or more GUI libraries, which define certain types of objects (e.g. "windows", "buttons") and certain events associated with them (e.g. a "button" is something that can be "clicked") and applications tend to use those. So the designer decides they're going to create a Windows application, or a Mac application, or (in the open source world) they'll use GTK or Qt or one of the other widget toolkits.

In the application the programmer basically only has to specify two things: 1) the types of objects they want (e.g. a "window" with a "menu bar" and some "buttons" and a "scroll window" in it) along with some properties (e.g. the title of the window, the text that appears on the buttons), and 2) what should happen when an event occurs (e.g. what should happen when a "button" gets "clicked"). All the rest - what windows actually look like, what scroll bars look like and how they behave, how buttons look when they're being clicked on - is defined by the GUI toolkit, and isn't under the application developer's direct control. So the scrolling behaviour you're describing is probably just the default or only way scroll windows behave in whatever GUI toolkit the application is using. If two different versions of the application exist (e.g. one for Windows and one for Mac), they might not even behave in exactly the same way.

As for why the scroll window acts the way it does, I can't imagine there's any specific reason for it. Probably the person who decided that had nothing to do with the people developing the torrent app, thought it was the simplest behaviour to implement, and wasn't thinking of rapidly growing lists at the time.

[Crunchy Cat]

Tiassa,

It's mostly a result of various pre-packaged list controls that programmers use. Writing good controls from scratch takes a long time and most developers use something standard / free.

[Chipz]

This happens because asychronous back-end processing for list composition is not properly controlled by the primary GUI thread interface. It is not hard to mutex lock list completion of a back-end thread base on GUI event processing. Whatever application you are using wasn't properly written.