[See Bugtracker] Group packages into a larger context

[madmax2]

Please add ability to organize packages within package or
Group into a larger context which a few other downloaders offer e.g. flashget etc.. please see flashget for what i mean for the features..

e.g. Movies, TV, Music, Software etc.. or adding tab or left panel with these context labels.

Right now the links/packages are a total mess.

If we can do

All items > xxx, yyy etc..
Movies > Package 1 > xxx.rar, xxx.r01
> Package 2 > yyy.
Music > Package 1 > zzz etc..

So if we want to only download movies we can click on the movies group/tab and just download that..

Or we if don't have a preference we can click ALL items...

Please see flashget for what I mean.

It makes it easier to organize packages.
Cos we might have added a lot of stuff and can't remember what context they were.

Also doing this would clean up the large package mess issue.
Since if we click on on Movies label, only movie packages show up.

==

also what about adding a Path label at the top.. as an option

and it has the link of where u downloaded/save the file to.
That way when u finished u can just click that link and open the folder where u downloaded like how it is done in flashget.

This would make it easier/user friendly to open the folders u want than the other method implemented.

Please, see also :-

1)

2) categories;

3)

[madmax2]

Originally Posted by remi

Please, see also :-

1)

2) categories;

3)

So does that mean it will get implemented or not?

btw it shouldn't be implemented like drbits said

ie a column for categories.

It should be a left panel like flashget..
where u only see the packages of the category that u selected..

Or if u selected ALL then u see all.

===

Also what are the chances the team port the code over to c, c# .net or c++ etc.. which has more flexibility in porting to other OS and also allows things like opening a filetype directly from jd rather than only being able to open the folder only

1) has been rejected and won't be implemented as long as the rejection isn't revoked. Note that I don't agree with that rejection.

2)

and 3) are still waiting for implementation. They both have a low priority.

Is it possible to show some screen shots from Flashget? I've never used it.

I think the remark about changing the implementation language won't be considered. Java is more popular than the other languages you cite. Java's main advantage is exactly its portability.

Opening files directly is possible in Azureus (Vuze), which is a nice Java application as well. This means you might consider it as a missing feature in jD.

[Jiaz]

open file is already possible in nightly and next public.
adding another subpackage level is not planed yet.

[madmax2]

Originally Posted by Jiaz

open file is already possible in nightly and next public.
adding another subpackage level is not planed yet.

I don't think adding another subpackage level is as good as having a left panel with categories already implemented
ie like flashget..

Originally I think I was the one that suggest subpackage but after using flashget etc.. I can see their method is more neater.

Also having a possibility adding your own categories is good as well but not a major needed feature since most stuff fall under the usual software, movies, music, tv etc.

Even though the jdownloader is the best downloader for hosting sites..
If u got a lot of packages it is a big mess like dumping all your stuff in one box.

==

also what about my other suggestion of putting "Path" as a label on the top..
So u can quickly click the link to open the folder of whichever package u downloaded.

Just look at flashget to see what i mean

[madmax2]

Originally Posted by remi

1) has been rejected and won't be implemented as long as the rejection isn't revoked. Note that I don't agree with that rejection.

2)

and 3) are still waiting for implementation. They both have a low priority.

Is it possible to show some screen shots from Flashget? I've never used it.

I think the remark about changing the implementation language won't be considered. Java is more popular than the other languages you cite. Java's main advantage is exactly its portability.

Opening files directly is possible in Azureus (Vuze), which is a nice Java application as well. This means you might consider it as a missing feature in jD.

But adding categories would really make a big improvement in organising the big mess of stuffing everything in one box..
I don't know why this would be considered low priority.
Was this put out 1 year ago?

How many ppl work on Jd in coding?
This reminds me of kmplayer. I think there is not much coders on it, so new releases are really slow, but still it is the best media player in my opinion.

So even though it is the best hosting downloader, but unfortunately new features like categories would take a really long time to get put in due to very low staff.

What other features are they mainly working on for next release?
==

But doesn't java hogged more memory than regular c or c++?

[madmax2]

removed..

[Jiaz]

i think categories will come when filter in view is added. that's the best for both i think:
1.) not making it too complicated, no suboackage level, no tabs
2.) filtering view can be good for more than just categories

I completely agree. KISS principle.

@madmax2

Have a look at jD's Roadmap.

I think there are enough potential java programmers, but they need to understand the design/architecture of jD before they can even start thinking of programming on jD.

Assembly language consumes even less memory. If java would consume too much memory why would it be supported by so many phones that have memories of a few MBs, not GBs?

[madmax2]

Originally Posted by remi

I completely agree. KISS principle.

@madmax2

Have a look at jD's Roadmap.

I think there are enough potential java programmers, but they need to understand the design/architecture of jD before they can even start thinking of programming on jD.

Assembly language consumes even less memory. If java would consume too much memory why would it be supported by so many phones that have memories of a few MBs, not GBs?

That is a poor example..

Because the app itself don't use that much memory.

I guess it comes down to the app..

All I know is right now, jd is not downloading but is hogging up to 200mb of ram.

The biggest ram hog is firefox though.
I saw it take like 1.4gb of ram before.
==

Also what i mean is features seems to take too long to get implemented.
I think categories was post 1 year ago.
How many coders actually work on jd?

Would making it open source speed things more like other popular software?

Also can u explain this filter in view is it same as the way flashget does it with it's left panel.

[madmax2]

Originally Posted by Jiaz

i think categories will come when filter in view is added. that's the best for both i think:
1.) not making it too complicated, no suboackage level, no tabs
2.) filtering view can be good for more than just categories

Well I trust you guys will come up with the right way to organise the package mess that we currently have.

It's funny, first there was the mess of all the links which got solve by using packages, now ppl got lots of packages which now goes back to the first problem again.

Can u tell me this view filter feature?
when would this be in?
Also is it similiar to flashget left panel method?

Just curious but how would filter view work?

If we click movies>
Then jd would autodownload all links in that section?

and if we click ALL>
Then jd would go thru the links in whatever order we put it as?

ie package 1 = games
package 2 = movie etc..

I think it is still necessary to have an all view..so incase I want to download package 1 = movies, then package 2 = app etc..

[Jiaz]

the nightly edition of jd already needs less ram. i saw users with only 32mb ram usage. but dont mix ram usage with process ram usage.
jd in taskmanager will show java+jd+heap

jd is already opensource.

once some work on the filtered view is done, i will provide more info as its still in planning phase.

@madmax2

What is a poor example?

jD is an open source project.

Please have a look at jD's developers page.

There are more important features like file renaming that are already waiting for several years. That feature has been asked a zillion times.

My browser currently uses only 104 MB with over 20 (stacked) tabs. My jD is currently using only 5 MB. Minimise jD's window and you'll see a huge difference.

As I already said I don't know Flashget.

[madmax2]

Originally Posted by remi

@madmax2

What is a poor example?

jD is an open source project.

Please have a look at jD's developers page.

There are more important features like file renaming that are already waiting for several years. That feature has been asked a zillion times.

My browser currently uses only 104 MB with over 20 (stacked) tabs. My jD is currently using only 5 MB. Minimise jD's window and you'll see a huge difference.

As I already said I don't know Flashget.

When I said poor example I mean saying that phones use the java and they don't take much memory therefore java doesn't take much memory, it has a flaw in the logic.

I guess it comes down to the app itself cos phone apps were programmed not to use much memory.

But jd does use a lot of memory.

See my attachment.
Currently downloading just one package and it's takes that much memory.
I have seen it go to about 400+ mb before.

==
Flashget is a free download manager

Also idm's method also good as well.

[Jiaz]

phone java NOT the same as full java 1.6 se.
201 = java +jd+heap (most of it heap)
use the nightly, disable unwanted columns and most important, close your windows---all that will reduce memload a lot.

[madmax2]

anyone know the expect timeframe for filter in view or categories implementation?

Look at the Roadmap (I replaced my outdated link in post #10).

- Feature #1234: Add categories to Packages & Download Units and
- Feature #1235: Filter, Search, and Sort on any grid column

are both in "JDownloader - FarfarAway". This release needs at least 194.50 hours to complete. It's possible that other features will be added.

The "Next Major Public Release 1.xxx" will need another estimated 95.25 hours.

I don't have statistics for the average hours of work done each day/week. If I would know it, I could provide estimates for an implementation of those features.

[drbits]

Features like Categories or Tags will be fit in somewhere in the future. There are some important and complex changes to be made to the program and "nice to have" features will be added as there is time. Each major release will probably have one or two major changes and a few new features.

Given the varying availability of developers and the shortage of available developers, there is no way to predict the time for the major releases or which features will be in which release.

The estimated hours are far off from reality. A lot of the developer work goes into fixing bugs as people find them. It is not clear which features will migrate to FarFarAway. In addition to what is in Nightly, this next release will probably have support for multiple proxies (or rotating proxies), improved download engine, and some progress in how status is reported.

Originally Posted by drbits

Given the varying availability of developers and the shortage of available developers, there is no way to predict the time for the major releases or which features will be in which release.

That's why I wrote about statistics, but I've the impression that most people don't like statistics.

Originally Posted by drbits

The estimated hours are far off from reality. A lot of the developer work goes into fixing bugs as people find them. It is not clear which features will migrate to FarFarAway. In addition to what is in Nightly, this next release will probably have support for multiple proxies (or rotating proxies), improved download engine, and some progress in how status is reported.

I can understand that estimating work effort depends a lot on experience. When I estimate efforts I always double or triple the effort at the end of my impact calculations, depending on the complexity of a project.

For each feature there should be time for requirements analysis, customer documentation, architectural and usability design, detailed design ((re)factoring), programming, unit testing, integration testing, acceptance testing and debugging.

All the parameters of development time can be statistically estimated and used throughout a project. A good way of obtaining these parameters when experience is lacking, is recording and measuring them for every feature/requirement. The collecting of these data should be automated as much as possible.
If programmers don't have much experience, debugging time, when expressed as a percentage of development time, will automatically increase.

The priority of features should be determined by customers and their feasibility should be determined by technical people.

Maybe the estimated development time is based on a bad approach. I don't know! But in common you achieve nested structures by simply adding parent_id's. I can't imagine jd2-dev's are not experienced enough to evaluated this very common approach.

Customer's that would benefit from this are those who have:
- low internet connection (Now I wanna load this series of packages, now this, then that, instead of having tons of packages related to the same subject to be sorted/enabled/disabled all time)
- low disk space and load/delete cycles all day
- organization neurosis

I sadly coun't myself to all 3. Not sure if we mean the same thing btw, one brought me here. I have a very simple explanation of a feature that seems simple and quick to be implemented, look up here: https://board.jdownloader.org/showthread.php?t=79319

[pspzockerscene]

Pusing this will not work as changing the current behavior is not an *easy* thing.

For now you will have to rely on downloadpaths with which you can archive the same but it just does not look as good as *folders in folders* inside jd.

-psp-