New Windows GUI prototype

Archive of historical development discussions
Discussions / Development has moved to GitHub
Post Reply
RandomEngy
Posts: 49
Joined: Thu Mar 29, 2007 2:56 am

New Windows GUI prototype

Post by RandomEngy » Sun Jan 10, 2010 11:47 pm

Hey everyone, been working on an alternate Windows GUI for a bit and I've got a prototype ready:

http://engy.us/misc/HandbrakeWpfPrototype-0.0.1.zip

Image

It's written in WPF, so you'll still need .NET 3.5. You'll also probably still need DVD43 or AnyDVD to rip DVDs. Right now it's running off the 0.9.4 CLI.

As you can see, I changed things around a bit. The primary motivation for doing this is getting a conceptual separation of what you want to encode and how you want to encode it. The "what" portion is on the main UI: the chapters, the audio tracks to include, the subtitles to add. The "how" is tucked away under the encoding section:

Image

Here's where you specify rules for handling picture settings, video encoding quality and filters, as well as how you want to encode any audio tracks you may have picked. The idea is you spend some time tweaking your encoding settings, then apply them to multiple tracks or movies. Optionally, you can tweak the encoding settings before each item. You can also create your own presets, or just use a "scratchpad" encoding profile which is automatically saved when edits are made. One thing to note is that the user presets and built-in presets have exactly the same power.

The queue is now also part of the main UI. I moved it here because it fits in with the workflow of the main form: you've got the encoding settings how you want them, now you want to do a bunch of ripping.

Also, as a side effect, the "big button ribbon" is gone. I thought its functionality was a little bit schizophrenic, so I broke it up. "Show queue" is gone, the "Select source" has been merged with the source label, the activity log will probably end up in a normal menu and the Start/Add to Queue buttons are down near the queue area where it makes sense from a workflow standpoint.

One more change I've made is getting rid of the popping up console windows. I realize that this means you need to kill the CLI process to stop it, but I figured I would explore the change (especially since the windows were driving me crazy). Anyway if we get standard input on the CLI or switch over to library calls, this won't matter so much.

I've also changed the preview to just simply open the file it's just created with whatever program the user has default for that extension in Windows: Neither Quicktime nor VLC are required. The in-UI quicktime thing never worked for me anyway.

Some other new stuff:
  • Multiple DVD drives supported.
  • Detects DVD eject/insert and automatically scans new discs.
  • Real-time previews of output picture display dimensions.
  • List items (audio encodings, subtitles) are editable directly on the list rather than requiring everything go through a single editing area.
  • Flexible window sizes, and smaller minimum window sizes.
  • Program remembers window sizes and locations.
  • Drag and drop reordering for queue items, subtitles and audio encodings.
  • Progress bar on the taskbar icon in Windows 7.
  • Both width/height and maxwidth/maxheight are visible and available for editing.
  • Encoding settings still available while scanning.
  • Explicit Save/Save As for user presets.
  • Instant UI updates when changing number fields.
Since this is a prototype, there's a lot of things not there yet, including:
  • Chapter markers (though I have a good idea of how I'm going to add them)
  • Advanced x264 options
  • Options dialog
  • Activity log
  • Menu, with help/exit/etc
  • Growl notifications
  • Drag and drop file on to UI to encode
  • The other presets
  • Queue recovery (would autosave and recover silently and automatically)
  • Angles
  • Preview button on the main UI (have not finalized where to put it yet, probably down near start/add to queue)
  • Program/Preset updates (need some work here, should probably version the preset XML so we can upgrade it if the structure changes)
For the most part, these would function identically to what's in the current UI. I left them out of the prototype because for the most part they are straightforward implementations which don't impact the main workflow. Though note that since the Options dialog isn't around yet, to change your output folder you'll need to edit the user.config XML in %localappdata%\Microsoft\HandBrakeWpf__ .

There's also some polish needed, such as icons on save, add, enqueue buttons, an animation for the "Scanning..." text, and lots more tooltips and warnings about restrictions that we apply.

One other note from an architectural standpoint is that the UI, program logic and preset format is completely separated from the idea of calling the CLI to do an encode. Changing the program to do P-Invokes into a library would be a relatively straightforward procedure. Also if you take a look at the source, you may notice it's written in MVVM. It's a bit weird at first, but I quite like it. It also lays groundwork for adding unit tests later if we feel like it (though my home copy of VS doesn't support unit test projects).

Anyway, what do you think of what's there? Comments, suggestions and criticism are all welcome.

rhester
Veteran User
Posts: 2888
Joined: Tue Apr 18, 2006 10:24 pm

Re: New Windows GUI prototype

Post by rhester » Mon Jan 11, 2010 7:34 pm

Honestly? I think any effort on a next-gen Windows GUI should be spent on tight integration with libhb rather than shimming it via CLI. It was a quick-and-dirty approach that is an extraordinary pain to maintain and keep consistent with other ports and stands as the only front-end that doesn't "speak libhb" natively.

I'm not trying to take away from what you're doing, I'm just suggesting that I think that the greater effort of genuine integration would be time better spent.

Rodney

RandomEngy
Posts: 49
Joined: Thu Mar 29, 2007 2:56 am

Re: New Windows GUI prototype

Post by RandomEngy » Mon Jan 11, 2010 8:52 pm

That's part of what this effort is. The current UI is steeped in the CLI interface. Presets are stored as CLI queries, UI panels are responsible for their "section" of the CLI query and even the UI layout mirrors the CLI structure.

The actual amount of code that touches the CLI in my prototype is pretty small and contained. You could swap it out with library calls without much trouble. The fact that I've been working a lot on the UI and usability does not in any way hinder a move away from the CLI.

dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Re: New Windows GUI prototype

Post by dynaflash » Mon Jan 11, 2010 9:18 pm

While I applaud the effort. Realize that the three gui's ( WinGui, MacGui, and LinGui ) generally mirror each other for a reason ( within practical bounds ). It is a conscious decision by the dev's to have that workflow. *Much* has been bandied about for new workflow designs and layouts but in general, a significant change to one necessitates a significant change to all from a user interface standpoint.

RandomEngy
Posts: 49
Joined: Thu Mar 29, 2007 2:56 am

Re: New Windows GUI prototype

Post by RandomEngy » Mon Jan 11, 2010 9:59 pm

What percentage of HandBrake's user base uses the GUI on multiple platforms?

dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Re: New Windows GUI prototype

Post by dynaflash » Mon Jan 11, 2010 10:24 pm

I have no clue, nor do I really care tbh. The project admins have made a conscious effort to maintain parity Gui-wise between platforms, that is all I am saying.

Edit: The point is this .... as the macgui maintainer there are many tweaks and changes I would personally ( and have on local versions ) changed which better fit *my* workflow. Even as an admin, when brought before the other devs and hashed out many of them were decided against. This is not because they are bad ideas, but rather it was determined that they were not in the best interest of the project direction. That is fine as hb ( in general, or the macgui in my case ) is not mine. How I use HB and how another person uses HB are two totally different concepts. I like everyone else has to concede to the projects best interest.

Is it me or did you flip the constant quality slider ?

dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Re: New Windows GUI prototype

Post by dynaflash » Mon Jan 11, 2010 10:52 pm

Giving this some thought ...
I applaud you're "elbow grease" in bringing a new idea to the hb wingui ui. Really I do. I have no interest in discouraging you. However maybe some discussion on our irc channels regarding a newer ui would make some sense here. most dev discussion really happens there.I want you to know that I am not trying to tromp on you're ideas. I have simply experienced with the MacGui , people tend to want it changed to match their workflow. Which is fine, but for a project to adopt that and adopt basically a new UI infrastructure, etc. there are other considerations. One big one would be who would maintain it. RIght now the wingui maintainer ( and creator for that matter ) is s55. What would happpen if this new model was officially adopted into hb as the new wingui and you disappear ? Who would maintain it ? Who would support it ? Who would add the many things you currently do not offer in your admitted "prototype" ? These things all weigh heavily on a project when adopting a new UI. Much discussion would be needed.

RandomEngy
Posts: 49
Joined: Thu Mar 29, 2007 2:56 am

Re: New Windows GUI prototype

Post by RandomEngy » Mon Jan 11, 2010 11:27 pm

dynaflash wrote:I have no clue, nor do I really care tbh. The project admins have made a conscious effort to maintain parity Gui-wise between platforms, that is all I am saying.

Edit: The point is this .... as the macgui maintainer there are many tweaks and changes I would personally ( and have on local versions ) changed which better fit *my* workflow. Even as an admin, when brought before the other devs and hashed out many of them were decided against. This is not because they are bad ideas, but rather it was determined that they were not in the best interest of the project direction. That is fine as hb ( in general, or the macgui in my case ) is not mine. How I use HB and how another person uses HB are two totally different concepts. I like everyone else has to concede to the projects best interest.

Is it me or did you flip the constant quality slider ?
I think it's a relevant question. If few people use the program on multiple platforms then you get far less benefit from standardizing the UI.

As far as the workflow goes, that's partly what this prototype is about. I wanted to get something that people could play with and compare with the current UI. I was not successful at all when attempting to communicate these ideas in the IRC channel. The first thing I want to figure out is if people like the workflow; if it makes sense in the way they do things. If people like it, go from there: see if it's worth it to have the Windows GUI break off a bit from the others, or to update the other UIs as well. If it's really fundamentally impossible to get this into Handbrake, I understand. But as you said, people may have different preferences and I think there may be a niche somewhere for this kind of approach. But the first step is figuring what people like and don't like about the prototype.

As for the constant quality slider, the implementation right now is just a number slider for the target quality, which in the case of x264 means to the right is lower quality. It's partly an initial implementation and partly an experiment on making the slider a bit more straightforward; I never liked that you had two numbers that change in opposite directions when you move the slider around. I had played with a reversed version of the slider, where moving to the right lowered the quantizer, but that just felt wrong to be moving a number slider to the right and watching a number decrease.
dynaflash wrote:Giving this some thought ...
I applaud you're "elbow grease" in bringing a new idea to the hb wingui ui. Really I do. I have no interest in discouraging you. However maybe some discussion on our irc channels regarding a newer ui would make some sense here. most dev discussion really happens there.I want you to know that I am not trying to tromp on you're ideas. I have simply experienced with the MacGui , people tend to want it changed to match their workflow. Which is fine, but for a project to adopt that and adopt basically a new UI infrastructure, etc. there are other considerations. One big one would be who would maintain it. RIght now the wingui maintainer ( and creator for that matter ) is s55. What would happpen if this new model was officially adopted into hb as the new wingui and you disappear ? Who would maintain it ? Who would support it ? Who would add the many things you currently do not offer in your admitted "prototype" ? These things all weigh heavily on a project when adopting a new UI. Much discussion would be needed.
Yeah, I was hanging out in the IRC channel for a bit before but just got completely swamped by people telling me not to make the prototype and that my software engineering approach was awful, and eventually got kicked while trying to defend myself. It was a bit high on drama and low on substance so I stayed out and buckled down for a while. But I'd love to participate in further discussions, if you'll have me. Anyway, I'd be happy to maintain the GUI if some form of it were accepted. I'm pumped up about it and have been putting in a lot of work and would love to stay on and maintain it. I love working on practical tools and usability challenges. Though in the end, whether you think I'm more likely than s55 to mysteriously vanish is going to be something that you'll have to decide. Anyway, it wouldn't have to be just me maintaining it.

As for the missing features, I'd add them. Most of them are going to be identical to current features so it's just a matter of sitting down and slamming them out. I tried to tackle all the hard and new design problems first. Also I'm posting it in an unfinished state to get feedback as early as possible. The prototype is just an arbitrary cutoff where it's far enough along to get a good sense of how it would function differently.

User avatar
Rodeo
HandBrake Team
Posts: 12086
Joined: Tue Mar 03, 2009 8:55 pm

Re: New Windows GUI prototype

Post by Rodeo » Mon Jan 11, 2010 11:42 pm

The UI is interesting and appears to work for the most part (though I did not try an encode).

The Picture tab gets most things wrong though.
  • in Strict anamorphic mode, the video is never scaled, so the PAR never changes. Your picture tab gets it right when there is no cropping (see Strict correct), but wrong otherwise (see Strict incorrect 1, Strict incorrect 2).
  • in Loose anamorphic mode, the storage dimensions (i.e. what you call Output: Source resolution) are scaled to mod 16 dimensions (the whole point of this mode). Your picture tab doesn't do that (it works if there is no cropping, but only because my source has mod 16 dimensions to begin with - see Loose correct).
    When there is cropping, your picture tab gets the PAR wrong (just like your Strict ana) and also doesn't set the storage dims to mod 16 (see Loose incorrect). What it should do is change the storage dimensions so that they divide cleanly by 16 and then adjust the PAR to preserve the source's display aspect ratio.
  • in None anamorphic mode, your picture tab forgets to adjust for cropping even though Keep Aspect Ratio is checked (see None incorrect).
  • in Custom anamorphic mode, your picture tab does not adjust the storage dimensions to the modulus like it should. Also, 0 / 0 is not a valid PAR (it's not even a number) so it's definitely not a good default (see Custom incorrect 1).
    Finally, when you specify the dimensions in HandBrake (width or height), you always specify dimensions after cropping. In Custom ana mode, your picture tab applies cropping to the specified dimensions (see Custom incorrect 2).
Also, as a side note, decomb and deinterlace shouldn't be applied simultaneously.

Here's an archive containing the screens I refer to in my post - you'll find screenshots of your UI (whether correct or incorrect) as well as screenshots of the MacGUI (with names matching the corresponding screenshot for your UI, but the correct storage and display dimensions).

http://localhostr.com/files/b5ece2/screens.zip

dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Re: New Windows GUI prototype

Post by dynaflash » Mon Jan 11, 2010 11:52 pm

RandomEngy wrote:Anyway, I'd be happy to maintain the GUI if some form of it were accepted. I'm pumped up about it and have been putting in a lot of work and would love to stay on and maintain it. I love working on practical tools and usability challenges. Though in the end, whether you think I'm more likely than s55 to mysteriously vanish is going to be something that you'll have to decide. Anyway, it wouldn't have to be just me maintaining it.
Well, in terms of who would mysteriously vanish, thats easy since s55 wrote the existing wingui back when it was not even part of the project and afaik in that sense is the longest lasting hb active dev we have. Realize that we have had many people come forth with ideas about supplanting exisintg ui's with their own ideas... from true working prototypes to photoshop unicorns. So if you sense some reticence among the active devs to bail on a long standing cornerstone of what hb offers, realize its not our first rodeo in this area. However, if you wish to talk and elaborate further jump back on irc. I will give you a listen at the very least. Again, be aware that the Gui's *will* retain some semblance of parity. So a massive change to one is a change to all.

RandomEngy
Posts: 49
Joined: Thu Mar 29, 2007 2:56 am

Re: New Windows GUI prototype

Post by RandomEngy » Mon Jan 11, 2010 11:59 pm

Rodeo:

Thanks for the feedback!

Most of the prediction function I made via trial and error. I worked for most crop/Anamorphic/PAR values I threw at it, but I'll certainly take a look at your screens and make appropriate fixes.

Though I thought I enforced only having one of decomb and deinterlace; I'll re-check that.

dynaflash:

I'll jump on IRC when I get home and finish my workout. Right now I'm at work and am limiting myself to a few forum posts.

TedJ
Veteran User
Posts: 5388
Joined: Wed Feb 20, 2008 11:25 pm

Re: New Windows GUI prototype

Post by TedJ » Tue Jan 12, 2010 1:33 am

RandomEngy wrote:What percentage of HandBrake's user base uses the GUI on multiple platforms?
While I understand the sentiment, you're asking the wrong question. The question you should be asking is, "How many developers are willing or able to maintain two or more separate documentation trees?"

The current interface, while not ideal for many people's workflows at least allows us to use the Mac GUI guide as the primary documentation, with addendum for the other ports as needed.

RandomEngy
Posts: 49
Joined: Thu Mar 29, 2007 2:56 am

Re: New Windows GUI prototype

Post by RandomEngy » Tue Jan 12, 2010 3:48 pm

Rodeo wrote:The UI is interesting and appears to work for the most part (though I did not try an encode).

The Picture tab gets most things wrong though.
  • in Strict anamorphic mode, the video is never scaled, so the PAR never changes. Your picture tab gets it right when there is no cropping (see Strict correct), but wrong otherwise (see Strict incorrect 1, Strict incorrect 2).
You're right about this. FFDShow was giving me an incorrect display aspect.
  • in Loose anamorphic mode, the storage dimensions (i.e. what you call Output: Source resolution) are scaled to mod 16 dimensions (the whole point of this mode). Your picture tab doesn't do that (it works if there is no cropping, but only because my source has mod 16 dimensions to begin with - see Loose correct).
    When there is cropping, your picture tab gets the PAR wrong (just like your Strict ana) and also doesn't set the storage dims to mod 16 (see Loose incorrect). What it should do is change the storage dimensions so that they divide cleanly by 16 and then adjust the PAR to preserve the source's display aspect ratio.
Right, fixed.
  • in None anamorphic mode, your picture tab forgets to adjust for cropping even though Keep Aspect Ratio is checked (see None incorrect).
In this case Keep Aspect Ratio will only change how the given dimensions are changed automatically. It's not actually passed in as an encoder parameter. So when all width/height/maxwidth/maxheight are blank, the Keep Aspect Ratio checkbox has no effect.
  • in Custom anamorphic mode, your picture tab does not adjust the storage dimensions to the modulus like it should. Also, 0 / 0 is not a valid PAR (it's not even a number) so it's definitely not a good default (see Custom incorrect 1).
    Finally, when you specify the dimensions in HandBrake (width or height), you always specify dimensions after cropping. In Custom ana mode, your picture tab applies cropping to the specified dimensions (see Custom incorrect 2).
Check. I hadn't quite figured out what I wanted for a default PAR value. I'll put some sensible default in there, like the source PAR if a source has been loaded or 1/1 otherwise.
Also, as a side note, decomb and deinterlace shouldn't be applied simultaneously.
Yeah, the UI is enforcing that.
TedJ wrote:
RandomEngy wrote:What percentage of HandBrake's user base uses the GUI on multiple platforms?
While I understand the sentiment, you're asking the wrong question. The question you should be asking is, "How many developers are willing or able to maintain two or more separate documentation trees?"

The current interface, while not ideal for many people's workflows at least allows us to use the Mac GUI guide as the primary documentation, with addendum for the other ports as needed.
That's a fair point.

henryfnord
Posts: 1
Joined: Wed Jan 13, 2010 8:39 am

Re: New Windows GUI prototype

Post by henryfnord » Wed Jan 13, 2010 8:55 am

RandomEngy,

Handbrake is multi-platform and with that comes the trade-off of a kind of clunky UI, that's the nature of the beast. Frankly, I love the product because the occasional UI annoyance is far less of a burden than the host of other things that Handbreak makes just work for the kinds of encoding I do. Also, I love that they're willing to make the big trade offs to do a job and do it very well.

If you're really jazzed about building a clean front-end to HB for Windows with the latest tech, I'd advise you to go off and spin up a project on CodePlex or something and do it. Be nice to the HB community and if you get far enough with a big enough audience you might make something happen. That's the beauty of open source.

RandomEngy
Posts: 49
Joined: Thu Mar 29, 2007 2:56 am

Re: New Windows GUI prototype

Post by RandomEngy » Thu Jan 14, 2010 2:20 am

I am actually leaning toward doing that at the moment. It doesn't look like there is much interest in updating the current UI.

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: New Windows GUI prototype

Post by jbrjake » Thu Jan 14, 2010 3:12 pm

RandomEngy wrote:It doesn't look like there is much interest in updating the current UI.
No, there is. Just not the way you've chosen to do it, and not unilaterally in one interface. As I explained to you, at length, in November, HB's interface and workflow are in the process of evolving to a point where the queue is autoloaded and, being modifiable, acts as a sort of document selector, with the main window acting as a basic document based app interface. To refresh you:
[20:28] [jbrjake] for example, are you aware that queue modification is a big deal for 0.9.5?
[20:29] [jbrjake] the ui model we are moving towards is that the queue window will be like a source selection window, and the main window is like the current document being edited
[20:31] [jbrjake] RandomEngy: so does the queue being a separate window make a little more sense to you if you realize that eventually the queue window will control the contents displayed in the main window, and the view might eventually be shifted to a sidebar like for itunes libraries?
[20:32] [RandomEngy] Is there a forum thread about this somewhere?
[20:32] [jbrjake] these are the sorts of things you can learn by actually talking through ideas with other people instead of telling them everything they do is crap and you are positive that you alone can do a better job.
[20:32] [jbrjake] no. it's the sort of thing you learn by being a member of the team.
[20:33] [jbrjake] and sticking around here and listening.
[20:33] [RandomEngy] Oh. So you have to idle in the IRC channel all the time.
[20:33] [jbrjake] as explained in our docs, the forum is secondary for dev work. primary communication happens right here on irc.
[20:33] [RandomEngy] wow
[20:33] [jbrjake] yes. in fact, we've refused interfaces before because their maintainers refused to stay in communication.
[20:34] [jbrjake] this makes us much more flexible about synchronizing changes between our three guis, for example.
[20:34] [RandomEngy] So maybe you have an ascii art mockup?
[20:41] [RandomEngy] But really I am interested in seeing mockups of your proposed queing UI
[20:43] [jbrjake] RandomEngy: it's just a consensus among the devs about where things are gong. it doesn't need a mockup. it's a pretty basic change built on an existing, widely-used ui metaphor.
[20:44] [RandomEngy] Okay. I know roughly what you're talking about. You add something, it pops up what is now the main window, you pick sources, encodings, etc and save it, then start the queue
[20:44] [jbrjake] a list of sources and a view to show and edit them individually
[20:45] [RandomEngy] I assume it will save the window state from last time so you can tweak a few input sources and save the next queue item
[20:45] [jbrjake] i'm talking about a modifiable queue. you load a source or sources into it. then you can move between them and edit settings in the main window. then you encode.
[20:45] [RandomEngy] Are the settings specific to a queue item?
[20:46] [jbrjake] again....a list of sources and a view to show and edit them
[20:46] [jbrjake] the main window is just a view of a source
[20:46] [jbrjake] in the queue
[20:46] [RandomEngy] Yes, I understand that
[20:46] [jbrjake] so of course they are specific to a queue item
[20:48] [jbrjake] see, we actually do think about this stuff. note how this ui concept avoids the pitfall i harped upon earlier -- you can't assume one size fits all settings will automagically work with a source. this allows an easy way to correct for items, after mass loading source items.
[20:49] [RandomEngy] Do all the items by default get the current encoding settings?
[20:49] [RandomEngy] Can you batch edit them?
[20:49] [jbrjake] when they are created they will be created with current settings, be they a preset or customized
[20:49] [jbrjake] so you will be able to batch load in with a preset, then verify all the items are properly configured. as the first is encoding, even.
[20:50] [RandomEngy] If you wanted to change, say, the audio bitrate on all of them, would you need to remove and re-add everything?
[20:50] [jbrjake] yes. which would be a matter of a few clicks.
[20:51] [jbrjake] (by the time this happens hb will be able to see a folder as a group of titles in a source, and probably have an option to add all titles to queue on load)
[20:51] [RandomEngy] All titles on a DVD?
[20:52] [jbrjake] well of course dvds matter less and less. one reason i'm skeptical of your ideas is your fixation on them even as hb moves away from them.
[20:52] [jbrjake] this is all stuff that will be collaborated on by the ui maintainers
[20:53] [jbrjake] i'm not going to restrict their options at this point. but there's no reason a checkbox list couldn't be a possibility. it's be done in hb before (see ihb)
[20:53] [jbrjake] (obviously just a "encode all titles" button wouldn't be helpful on a dvd when you only want certain titles)
[20:53] [RandomEngy] Yeah
[20:54] [jbrjake] but it's a tradeoff the ui maintainers will decide upon.
[20:55] [jbrjake] as a group.
[20:55] [RandomEngy] Well obviously it's harder to critisize and unwritten UI
[20:56] [RandomEngy] If their drastic redesign fixes everything, that's great
[20:56] [RandomEngy] *an
[20:58] [RandomEngy] Would this redesign also be able to detect when a DVD is inserted or changed?
[20:59] [RandomEngy] Would each queue item have the preset name by it, like iPod, then if the preset had been changed, have a marker for it?
[20:59] [RandomEngy] Like "iPod *" or some indicator of which ones had been fiddled with
[20:59] [RandomEngy] Is there ANY doc out there about this proposal?
[21:00] [jbrjake] huh? i'm not talking about a drastic redesign?
[21:00] [jbrjake] i'm talking about a logical progression from current capabilities like queue modification and upcoming already written code like folder-as-titles scanning, with only slight changes to the visible interface, and workflow modifications that merely extend the current process by allowing more flexibility.
[21:00] [jbrjake] someone would be able to continue to use hb the way they do now, and never even notice the new functionality. but if they need it, it will be there.
[21:00] [RandomEngy] But you're talking about having the main window be the queue window
[21:00] [jbrjake] no, i'm not
[21:00] [jbrjake] the main window is the main window is the main window
[21:01] [RandomEngy] Oh you mean that when you click on a queue item it modifies the main window to reflect the settings of that queue item?
[21:06] [RandomEngy] Ahh, I see. This is just a simple implementation of batch adding items from a source
[21:06] [jbrjake] the queue will be like an inspector to set the main window's contents
[21:06] [jbrjake] no for [Censored]'s sake there is not a "doc" about this. we are not a company outputting white papers to attract investors.
[21:06] [jbrjake] detected when a dvd is inserted or changed? piddly system specific concern i don't care about. you're a fool to use the optical drive for serious encoding anyway.
[21:06] [jbrjake] every queue item already has its settings listed and visible
[21:06] [jbrjake] i'm kind of scared here.
[21:06] [jbrjake] i already explained this and you said you understood.
[21:06] [jbrjake] the queue window will be a list of source items and the main window will be the view to edit them individually.
[21:06] [jbrjake] like selecting a library from the itunes sidebar.
[21:07] [jbrjake] you understand mvc, yes? the queue list is the model. the queue window is a view of the list. the main window will be a view of an item on the queue.
[21:07] [RandomEngy] Whoa all your stuff got backed up and it's just coming in
[21:07] [RandomEngy] Yeah I'm writing in MVVM
[21:08] [RandomEngy] Yeah and I was asking for a doc, a forum topic or SOMETHING I can read that doesn't involve you explaining it all over again
[21:09] [RandomEngy] Because as much as I love pestering you I think something that is posted somewhere would be a bit more permanent and not rely on all interested parties having idled in the IRC chat room at the correct time
[21:10] [RandomEngy] You don't need investors for that to be a good idea
[21:10] [jbrjake] why? all interested parties with a need to know were in on the discussions. that's what collaboration is about. a need for a doc would indicate we aren't communicating well as a group. i'm just distilling for you what we're already planning on doing in the future. you knowing about it doesn't change anything.
[21:11] [jbrjake] this was all hashed out when john and joe first started playing around with queue modification and it's being slowly ramping up ever since.

RandomEngy
Posts: 49
Joined: Thu Mar 29, 2007 2:56 am

Re: New Windows GUI prototype

Post by RandomEngy » Thu Jan 14, 2010 6:14 pm

Yes, I'm aware of your planned updates. I don't think there's any reason a modifiable queue is incompatible with any of the proposed changes. And this isn't a suggestion for a "unilateral change to one interface." It's a demonstration of some ideas for UI updates. I've heard a bit of feedback that some people wouldn't want the extra click to get to the encoding settings, which I think could be fixed by making the settings a separate window rather than a dialog, which could be placed side-by-side with the main window. However beyond that little bit of feedback, I'm not really sensing much enthusiasm for discussing, much less adopting any of the proposed changes, which, as people have stated, would have to apply to the other UI implementations as well.

Which brings me to why I'm entertaining your idea of doing a separate project.

Post Reply