Windows Desktop Analysieren?

Hey Leute.
Ich will ein kleines Spielchen schreiben, bei dem kleine Monster den eigenen Desktop auffressen und und… naja.

Dafür brauche ich irgendwie die Informationen des Windows Desktops das heißt die einzelnen Items die sich dort befinden - icons, name, position und größe.
Lässt sich das irgendwie, vielleicht mit C oder irgendwelchen native sachen ermitteln?
Außerdem bräuchte ich natürlich den Hintergrund des Benutzers.

An die Element Namen kann man ja einfach kommen in dem man den Desktop Ordner als Array nimmt, aber mehr ist ja eigentlich nicht drin,
ich komm mit java ja nicht an die icons… oder?..

*** Edit ***

geschweige denn position und größe auf dem windows desktop, denn das ist ja windows spezifisch…

*** Edit ***

Ha, nochmal geguckt, mit FileSystemView kommt man wohl an die Icons.
Fehlt noch position und größe auf dem desktop…

Grundsätzlich dürfte dafür native-Code notwendig werden. Ob man sich die Mühe machen muss eine eigene JNI-DLL zu schreiben oder von außen über JNA ran kommt muss man ausprobieren denn es ist leider nicht alles mit JNA so einfach umsetzbar wie es uns das MSDN glauben machen will, gerade was verschachtelte anonyme STRUCT angeht (wir hatten diesbezüglich mal n Thema).
Bezüglich der ICO : es gibt Libs die aus ICO/DLL/EXE-Daten für Java nutzbare RAW-Daten lesen können so das man diese dann manipulieren und zum Selbstzeichnen nutzen kann. Da würde ich nicht versuchen das Rad neu erfinden zu wollen sondern auf vorhandenes zurückgreifen.

Alles in allem recht witziges Vorhaben (als Beispiel könnte man z.B. “Stick Man” sehen wo sich ein Graphiker sehr viel Mühe gegeben hat), aber ganze direkt dynamisch laufen zu lassen sehe ich dann doch eher als Mammut-Projekt, für einen nur schwer bis nicht realisierbar und mit Java auch nicht wirklich die beste Sprache gewählt da wie gesagt native-Code nötig wird.
Sowas gehört dann wohl doch eher in die M$-Domäne wie DotNET/C#.

Mh, so komplex soll das nicht werden.
An sicht ist das ganze kein Problem für mich.
Ich brauch halt nur irgendwie diese informationen … ist mir ja egal wie, von mir aus native,
aber ich kann kein bisschen c ._.

An die Bilder bin ich gekommen, aber nur in der größe 32x32… ._.

try{
	images = new ArrayList<>();
	File desktop = new File(System.getProperty("user.home") + "\\Desktop\\");
	File desktopFiles[] = desktop.listFiles();
        for(File f : desktopFiles){
		Icon c = FileSystemView.getFileSystemView().getSystemIcon(f);
		BufferedImage image = new BufferedImage(c.getIconWidth(), c.getIconHeight(), BufferedImage.TYPE_INT_ARGB);
		c.paintIcon(null, image.getGraphics(), 0, 0);
		images.add(image);
	}
}
catch(Exception e){
	e.printStackTrace();
}

*** Edit ***

Hab hier was gefunden, C technisch, versteh aber leider nix…
jemand ne idee wie ich das in java einbinden könnte? (kompilieren und irgendwie als native methode einbinden?)
link

Gut, das mit dem 32x32 ergibt sich ja nun aus der DOC und dem Ort (und damit erkennbar die eigentliche Verwendung dieser Klasse) : es ist halt nur die skalierte Darstellung im FileChooser. Wenn du an die richtigen ICOs kommen willst brauchst du wie gesagt ne Lib die das Source-File liest und daraus die korrekten RAW-Daten ziehen kann, was wiederum erfordert das du erstmal das LNK ausliest um zu wissen von wo aus das ICO geladen wurde. Zum Auslesen des LNK kann ich JShortCut empfehlen, für ICO hatte ich auch mal was, müsste ich aber noch mal googlen.

Und selbst wenn du dann entsprechend die ICOs und den Background hast müsstest du, wenn es richtig vollwertig sein soll, auch noch die Taskbar emulieren und das ganze dann als FullScreen laufen lassen. Sicher, alles machbar und basiert eigentlich nur auf Bild-Manipulation, aber vielleicht wäre es einfacher einen Screenshot zu nehmen und zu versuchen diesen zu analysieren (was natürlich bei komplexen Backgrounds schön aufwändig werden dürfte).

Wie gesagt : die Idee finde ich super, aber das ganze mal eben so aus dem Ärmel on-the-fly schütteln, dafür dürfte es schon ein paar Tausende Code-Zeilen brauchen.

eben deshalb will ich es vereinfachen - taskbar zum Beispiel schneide ich echt einfach aus einem screenshot den ich dann mache raus.
(nur das man da auch die taskleisten höhe und position bräuchte…, ansonsten einfach weglassen, soll halt nur so ein “on-the-fly” projekt werden :D)

bildanalyse, ja viel spass… analysier mal… xD

kannst du c?
was sagst du zu dem link den ich gepostet hab?
Gibt es da brauchbare sachen?

*** Edit ***

Hab irgendwo noch folgendes Snippet gefunden:

...  
//Create a temporary file with the specified extension  
File file = File.createTempFile("icon", ".doc");       
  
ShellFolder shellFolder = ShellFolder.getShellFolder(file);      
Icon icon = new ImageIcon(shellFolder.getIcon(true));  
  
//Delete the temporary file  
file.delete();  ```

Hm, was ist dieses sun.awt.shell.ShellFolder..? 

Damit soll man jedenfalls die großen Icons bekommen können.

Mit Java würde ich das gar nicht versuchen, weil das in Gefrickel enden wird. Das ist so windowsspezifisch, dass da eine .NET-Sprache, wie @Sen-Mithrarin schon sagte, deutlich besser geeignet ist.

Aber ich brauch die daten doch nur einmalig… zu beginn…
und man kann doch c sachen benutzen…
wirklich keine chance?

Funktionieren würde es sicherlich. Aber es ist deutlich komplizierter als mit einer Sprache, die sehr eng mit der Windows API verzahnt ist.

naja - weisst du denn, oder jemand, wie es nun mit C gehen könnte?
Also diese Infos beschaffen…

Das lässt sich super Googeln und es gibt erstaunlich viele relevante Treffer. Fang halt mal hier an. Von nichts kommt nichts.

Und mit JNA ist nativer Code auch aus Java heraus relativ einfach nutzbar ohne dass man selber welchen schreiben muss.

Jo, hab ich bereits. Genau so, und bin dabei, wie auch durch deinen link
auf den bereits geposteten foren thread gestoßen: http://social.msdn.microsoft.com/Forums/windows/en-US/d7df8a4d-fc0f-4b62-80c9-7768756456e6/how-can-i-get-desktops-icons-information-?forum=winforms
Dort sind anscheinend code snippets gelistet, die tun was sie sollen.

Tut es das denn?

Aber ich denke ich mach mir jetzt mal die Mühe, und schau wie das funktioniert…
ich wollt halt wissen ob mir jemand von vornhinein hätte sagen können “das wird nicht gehen weil…”.
Naja egal. ran an native code benutzung in java…

Nun, “geht nicht, weil …” ist nicht ganz korrekt, möglich ist es durchaus, aber mit Java ein ziemlicher Aufwand. Selbst wenn man sich JNA zu nutze macht und es halbwegs sauber hinbekommt die MSDN-Doc nachzubauen denke ich doch eher das man mit DotNET/C# deutlich besser bedient ist. Eine direkte Verbindung zwischen Java und C# ist meines Wissens nach leider nicht möglich, und Java dann nur noch zu nutzen um halt die gewünschten Animationen zu berechnen und es dann wieder an die Win-API zurückzuschicken, hmm, für sowas ist Java weder gedacht noch ist es in irgendeiner Art wirklich sinnvoll.
Gerade bei diesem Topic zeigt sich mal wieder : mit Java kann man (mitlerweile und dank zahlreicher Libs) sehr viel machen, aber eben leider nicht alles.

Hä?

Ich glaub du verstehst nicht ganz worauf ich hinauswill.
Die Animation und das Spiel an sich würde ich mit Java und Lwjgl schreiben. (Also Opengl)

Ich hab mir das so vorgestellt:
Ich hab irgendwo ein c programm, das mit einfach nur die position und größe der items als ints übergibt, x y, width height.
Das ruf ich dann mit java einmal irgendwie auf, und hab halt ein array aus jeweils 4 mal ints, irgendwie.
Für den Rest brauch ich ja kein C…

Versteht ihr? Ich brauch nur einmal diese Zahlen… und die will ich an java irgendwie weiterreichen

Ja, das habe ich schon beim ersten mal verstanden, und dir auch schon beim ersten mal gesagt das du dafür native-Code brauchst. Ob nun JNI oder JNA, ohne gehts nicht.
Auch : „OpenGL-3D“ > würde ich schon aus Performance-Gründen direkt als Native schreiben, was bei rauskommt wenn man noch Java oben drauf klebt kennen wir alle von Minecraft.
Oder mal anders : warum denn bitte überhaupt 3D ? Auch wenn seit Vista mit Aero der DWM selbst in Direct3D (DirectX) rendert muss man das doch nicht für eine einfache Bild-Manipulation nachmachen. Mir ergibt sich da der ganze Aufwand garnicht sich extra in GL einarbeiten zu wollen und aufwändig irgendwelche Polygone berechnen zu müssen anstatt mit vorhanden 2D-Algorithmen wie man sie aus Photoshop kennt einfach auf nem Byte-Array zu arbeiten und das ganze dann ziemlich primitiv über z.B. JPanel darzustellen.

Aber immer mache mal, bin mal aufs Ergebnis gespannt.

[QUOTE=Sen-Mithrarin]Ja, das habe ich schon beim ersten mal verstanden, und dir auch schon beim ersten mal gesagt das du dafür native-Code brauchst. Ob nun JNI oder JNA, ohne gehts nicht.
Auch : „OpenGL-3D“ > würde ich schon aus Performance-Gründen direkt als Native schreiben, was bei rauskommt wenn man noch Java oben drauf klebt kennen wir alle von Minecraft.
Oder mal anders : warum denn bitte überhaupt 3D ? Auch wenn seit Vista mit Aero der DWM selbst in Direct3D (DirectX) rendert muss man das doch nicht für eine einfache Bild-Manipulation nachmachen. Mir ergibt sich da der ganze Aufwand garnicht sich extra in GL einarbeiten zu wollen und aufwändig irgendwelche Polygone berechnen zu müssen anstatt mit vorhanden 2D-Algorithmen wie man sie aus Photoshop kennt einfach auf nem Byte-Array zu arbeiten und das ganze dann ziemlich primitiv über z.B. JPanel darzustellen.

Aber immer mache mal, bin mal aufs Ergebnis gespannt.[/QUOTE]

dadurch merke ich… das du scheinbar recht wenig verstehst :smiley:

  1. Das Gerücht Minecraft sei langsam / schlecht whatever, weil es mit Java geschrieben würde, ist völliger müll.
  2. Ich lerne OpenGL seit nem Jahr. Ob man nun opengl mit java, c oder whitespace programmiert ist völlig egal.
  3. OpenGL hat nichts mit 3D zu tun. Es geht nur um Grafikprogrammierung, und oben genanntes projekt wäre natürlich 2D.
  4. Ich habe verstanden dass ich dazu natives brauche. aber statt einem gewurstel, also einem programm das irgendwie halb in java
    und halb in c läuft will ich ein Java Programm schreiben - welches am Anfang einmalig ein paar ints aus einem c programm zieht
  5. Ja ginge auch mit java2D. Aber da ich Opengl bereits „kann“, passt es doch.